Kernel Traffic #251 by Zack Brown
[email protected] Mon, 09 Feb 2004 00:37:48 -0800
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <[email protected]> |
Kernel Traffic #251 For 9 Feb
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 15 Jan - 21 Jan (11 Support For Infrared Remotes In 2.4 And 2.6
posts)
2. 15 Jan - 20 Jan (11 Altix Updates
posts)
3. 15 Jan - 21 Jan (31 Linux 2.6.1-mm4 Released
posts)
4. 16 Jan - 23 Jan (33 KGDB 2.0.3 Released
posts)
5. 16 Jan - 21 Jan (25 C++ Modules And Kernel Code
posts)
6. 16 Jan - 21 Jan (18 Some Discussion Of Maintainership And Patch
posts) Acceptance Policy
7. 16 Jan - 22 Jan (5 ReiserFS Support For laptop_mode
posts)
8. 17 Jan - 20 Jan (9 Modular IDE For 2.6
posts)
9. 18 Jan - 29 Jan (62 Software Suspend On PowerPC
posts)
10. 18 Jan - 20 Jan (16 Fix For ide-scsi Crash; Some Discussion Of
posts) Whitespace Patches
11. 19 Jan - 24 Jan (32 ALSA Vs. OSS Sound Support
posts)
12. 19 Jan - 20 Jan (5 Net Device Error Logging Macros For Drivers
posts)
13. 20 Jan - 22 Jan (40 Linux 2.6.1-mm5 Released
posts)
14. 20 Jan - 21 Jan (9 Status Of HPT370 Under 2.4 And 2.6
posts)
15. 20 Jan - 21 Jan (4 KGDB 2.0.5
posts)
16. 20 Jan (1 AGPGART Preliminary SiS648 Support
post)
17. 20 Jan - 24 Jan (11 Linux 2.6.2-rc1
posts)
18. 21 Jan - 26 Jan (64 Kernel Sub-Project Mailing List Posting
posts) Policies
19. 21 Jan - 22 Jan (6 SiSFB Update For 2.6.1
posts)
20. 21 Jan - 22 Jan (13 Data-Flushing Prior To Software Suspend
posts)
21. 22 Jan (18 Linux 2.6.2-rc1-mm1 Released
posts)
22. 22 Jan (1 udev 014 Relesed
post)
23. 22 Jan - 24 Jan (6 Support For VT6410 IDE/RAID Chipset In 2.6
posts)
24. 22 Jan (2 Status Of ATARAID In 2.6
posts)
25. 22 Jan - 26 Jan (7 PowerMac Update
posts)
26. 22 Jan - 28 Jan (4 memblks Leaving The 2.6 Tree
posts)
27. 23 Jan - 25 Jan (24 Linux 2.6.2-rc1.mm2 Released
posts)
28. 23 Jan - 25 Jan (10 Exporting Kernel Headers To User-Space;
posts) Stablizing The Kernel ABI
29. 23 Jan - 27 Jan (16 Linux 2.4.25-pre7 Released; Status Of 2.4
posts) Deep Freeze
30. 23 Jan - 26 Jan (3 IrDA Serial Dongle Support In 2.6 Reaching
posts) Parity With 2.4 Support
31. 23 Jan - 28 Jan (8 Status Of ext3 In 2.2 Kernels
posts)
32. 24 Jan (14 Forcedeth Update For 2.4; Some Developer
posts) Confusion
33. 24 Jan - 26 Jan (3 Linux 2.6.2-rc1-mm3 Released
posts)
34. 25 Jan - 26 Jan (15 IMQ Forward-Ported To 2.6; Inclusion Still In
posts) Question
35. 25 Jan - 29 Jan (21 Cooperative Linux: Running Linux Under
posts) Windows And Other Systems
36. 25 Jan (2 drivers/net/de6* Needs A Maintainer
posts)
37. 26 Jan (1 perfctr 2.6.5 Released
post)
38. 27 Jan (1 FUSE 1.1-pre2 Released
post)
39. 27 Jan (2 ALSA 1.0.2 Released
posts)
40. 27 Jan - 28 Jan (7 Binary-Only Nvidia Drivers For 2.6
posts)
Mailing List Stats For This Week
We looked at 2581 posts in 12381K.
There were 685 different contributors. 355 posted more than once. 279 posted
last week too.
The top posters of the week were:
* 113 posts in 503K by Andrew Morton
* 53 posts in 190K by Rusty Russell
* 50 posts in 217K by Pavel Machek
* 46 posts in 274K by Adrian Bunk
* 45 posts in 201K by Benjamin Herrenschmidt
* Full Stats
1. Support For Infrared Remotes In 2.4 And 2.6
15 Jan - 21 Jan (11 posts) Archive Link: "[patch] v4l-05 add infrared remote
support"
People: Gerd Knorr, Rusty Russell
Gerd Knorr said, "This patch adds a module with some helper functions to handle
infrared remotes using the linux input layer. It doesn't do any useful stuff
alone, but the saa7134 and bttv drivers will use that to support the remotes
shipped with some TV cards." Rusty Russell suggested updating the code to use
the new module_param() code from 2.6, but Gerd said, "No. The code in question
must also build on 2.4 kernels which don't have module_param(). And I don't
want to clutter up the code with #ifdefs unless I absolutely have to. I'll do
for the bttv ir support, that is 2.6 only anyway due to the usage of tasklets."
Rusty said this would be fine, and that "I'll write and test the forward compat
macros for 2.4, submit them to Marcelo, and then bother you again 8)" . He
posted the compatibility patch a couple of hours later, adding, "It doesn't do
arrays or strings, but they can be added if required." Gerd said array support
would be in his module code, so it would be useful to have it in 2.4 as well.
Rusty was reluctant, and they took the discussion off-line.
2. Altix Updates
15 Jan - 20 Jan (11 posts) Archive Link: "[PATCH 2.6] Altix updates"
People: Andrew Morton
Pat Gefre posted his latest set of Altix patches (ftp://oss.sgi.com/projects/
sn2/sn2-update/) for 2.6, and Andrew Morton replied, "I'll assume these are for
review at this time. When that is complete, please send them over, one
changelog+patch per email in the time-honoured manner, thanks." Meanwhile, Pat
and Christoph Hellw went back and forth on technical problems for awhile.
3. Linux 2.6.1-mm4 Released
15 Jan - 21 Jan (31 posts) Archive Link: "2.6.1-mm4"
Topics: FS: NFS, Hot-Plugging, User-Mode Linux
People: Andrew Morton, Valdis Kletnieks, Prakash K. Cheemplavam
Andrew Morton announced 2.6.1-mm4, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1/
2.6.1-mm4/
+ There's a patch here which changes the ia32 CPU type selection. Make
sure you go in there and select the right CPU type(s), else the kernel
won't compile. We might need to set a default here.
+ Kernel NFS server update
+ MD update
+ V4L update
+ A string of fixes against the parport, paride and associated drivers
+ Update to the latest UML
+ Patches to support gcc-3.4 on ia32. There is more to do here - more
warnings need to be fixed and the exception tables need to be sorted. I
didn't add the `-Winline' patch because it's way too noisy at present.
Prakash K. Cheemplavam reported lockups, which he'd had with earlier kernels as
well. Valdis Kletnieks suggested, "If this is the NVidia graphics driver, it's
been doing it at least since 2.5.6something, at least that I've seen. It's
basically calling pci_find_slot in an interrupt context, which ends up calling
pci_find_subsys which complains about it. One possible solution would be for
the code to be changed to call pci_find_slot during module initialization and
save the return value, and use that instead. Yes, I know this prevents
hotplugging. Who hotplugs graphics cards? ;)"
4. KGDB 2.0.3 Released
16 Jan - 23 Jan (33 posts) Archive Link: "KGDB 2.0.3 with fixes and
development in ethernet interface"
Topics: Networking
People: Amit S. Kale, Matt Mackall, Pavel Machek, Jeff Garzik, Andi Kleen
Amit S. Kale said:
KGDB 2.0.3 is available at http://kgdb.sourceforge.net/kgdb-2/
linux-2.6.1-kgdb-2.0.3.tar.bz2
Ethernet interface still doesn't work. It responds to gdb for a couple of
packets and then panics. gdb log for ethernet interface is pasted below.
It panics and enter kgdb_handle_exception recursively and silently. To see
the panic on screen make kgdb_handle_exception return immediately if
kgdb_connected is non-zero.
Panic trace is pasted below. It panics in skb_release_data. Looks like skb
handling will have to changed to be have kgdb specific buffers.
Andi Kleen asked if Amit had used some recent netpoll patches, and Amit
replied, "I am not using netpoll (yet). My patch doesn't require any driver
modifications, that the mm ethernet patch required." Pavel Machek asked if this
meant Amit would eventually use netpoll, and Amit replied, "I don't know yet. I
don't like the idea of a debugger using a lot of kernel code. I am trying to
implement kgdboe without netpoll and without making changes to ethernet
drivers. Perhaps I'll have to use netpoll eventually!" Close by, Matt Mackall
remarked, "I went the no-modified-drivers route originally and a long
discussion with Jeff Garzik eventually convinced me of the error of my ways.
There are a bunch of paths that are racy if you try to make a generic poll
function."
5. C++ Modules And Kernel Code
16 Jan - 21 Jan (25 posts) Archive Link: "Compiling C++ kernel module +
Makefile"
People: Richard B. Johnson, Bart Samwel, Linus Torvalds
Someone was having trouble porting their C++ module from the 2.4 kernel into
2.6, and Richard B. Johnson said, "There is no C++ runtime support in the
kernel for C++. Are you sure this is a module and not an application? Many
network processes (daemons) are applications and they don't require any
knowledge of kernel internals except what's provided by the normal C/C++
include-files." Bart Samwel confirmed that this was indeed a module, adding,
"It includes a kernel patch that makes it possible to include a lot of the
kernel headers into C++, stuff like changing asm :: to asm : : (note the space,
:: is an operator in C++) and renaming "struct namespace" to something
containing less C++ keywords. The module also includes rudimentary C++ runtime
support code, so that the C++ code will run inside the kernel. I'm afraid that
the task of compiling it for 2.6 is going to be pretty tough -- the kernel
needs loads of patches to make it work within a C++ extern "C" clause, and it
probably completely different patches from those needed by 2.4. Getting the
build system to work is the least of the concerns." Richard thought the whole
exercise was a waste of time, and that C++ had no place in the kernel. "Next
thing it'll be Visual BASIC, then Java," he said.
Bart replied (disclaiming involvement with the module in question), explaining
that the code had originally been in C++, encompassing hundreds of files; and
that the work of porting all that to C for Linux, was comparable to the work of
modifying the kernel to accept a C++ module. He went on, "I expect that they
decided to do C++ because the model they try to express is best modeled using
C++. This design decision can be debated, because it is perfectly feasible
(albeit with a lot more work) to implement an OO model in C. In fact, I have
helped to implement a similar framework (the OKE CORRAL) which was written
completely in C. But, the fact of the matter is, this useful (but huge) kernel
module is there now (and it has been here since the early 2.2 kernels), and it
was not written just to "prove" that it could be done, but because C++ seemed
at the time to be the best language for the job. The start of this project may
very well predate the many times that this was hashed-over on the LKML."
Later, Bart said that the module authors "have never asked the kernel
developers to change. They've simply taken a language with an excellent C
interoperability layer, which can compile to object code that contains only
exported symbols with C-linkage, and they have restricted themselves to a
subset of that language that doesn't break the C code they're interoperating
with. This has become possible only because of the freeness of the kernel
(which is encoded in the license and further enforced by things like
EXPORT_SYMBOL_GPL), which allowed them to modify the kernel headers in order to
get it to compile in an extern "C" clause in C++. They've maintained this patch
since 2.2, and I don't expect this to change. I've even heard I don't think
_they_ expect this to change, as they probably know all too well about the
political climate within the kernel developers' scene. However, as long as the
kernel keeps using C as it's language, keeps being GPL'ed, and keeps exporting
a module interface that is defined by some prototypes in some C include files,
I don't see how this could lead to any trouble for them. They can always
maintain and distribute their patch (because of the freeness), they can always
link in their C++ code as a module (because of the module layer) and they can
always use the kernel's header files to import the module ABI for the current
kernel (because they are C files, and because C++'s extern "C" will always be
able to parse them -- except for some small fragments maybe, which might
require a patch)."
There was a bit of C-vs.-C++ debate, and at one point Linus Torvalds remarked:
in Linux we did try C++ once already, back in 1992.
It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.
The fact is, C++ compilers are not trustworthy. They were even worse in
1992, but some fundamental facts haven't changed:
+ the whole C++ exception handling thing is fundamentally broken. It's
_especially_ broken for kernels.
+ any compiler or language that likes to hide things like memory
allocations behind your back just isn't a good choice for a kernel.
+ you can write object-oriented code (useful for filesystems etc) in C,
_without_ the crap that is C++.
In general, I'd say that anybody who designs his kernel modules for C++ is
either
1. looking for problems
2. a C++ bigot that can't see what he is writing is really just C anyway
3. was given an assignment in CS class to do so.
6. Some Discussion Of Maintainership And Patch Acceptance Policy
16 Jan - 21 Jan (18 posts) Archive Link: "AIC7xxx kernel problem with 2.4.2
[234] kernels"
People: Xose Vazquez Perez, James Bottomley, Justin T. Gibbs, Linus Torvalds
In the course of discussion, Xose Vazquez Perez said that the aic7xxx driver in
the kernel was lagging far behind the driver released by Adaptec. He added, "It
looks like the _kernel_ driver is going to be without a maintainer unless
somebody works on it, porting ADAPTEC fixes/features to the kernel driver."
James Bottomley said, "this is *not* the way I see it. At the moment, Ataptec
is the maintainer of that driver unless they choose formally to relinquish it."
Justin T. Gibbs asked, "Can you provide your definition of "maintainer"? I know
that I am maintainer of the drivers distributed from my website, but I don't
feel I have ever been maintainer of the drivers in the 2.4.X, 2.5.X, or 2.6.X
trees." James replied, "A maintainer is a person who works with the kernel
community to keep the driver (or subsystem, filesystem or whatever) up to date.
Such a person may or possibly may not have an entry in the MAINTAINERS file."
Justin said, "Does the maintainer have the ability to veto changes that harm
the code they maintain? In otherwords, you claim that I am the maintainer of
the drivers in the kernel.org tree. This has not prevented changes from being
made to these drivers without adequate review. Even your last update to the
driver threw away all of the changelog state and left at least the aic79xx
driver in a worse state than it was in before (see changelog entries for the
driver versions after the one that you imported for details - this was exactly
why I didn't submit that particular revision). You didn't even bother to ask me
if importing 1.3.11 was appropriate. This is why I say I don't feel like a
maintainer. I'm not given adequate control over the end product yet I'm
supposed to take the blame when it doesn't work." Linus Torvalds replied that
actually, nobody had the right to absolutely veto a code change. He went on:
Even _I_ don't veto changes that the right people push (my motto:
"everybody is wrong sometimes: when enough people complain, even I am
wrong").
In particular, maintainers of "conceptually higher" generally always have
priority. If Al Viro says a filesystem is doing something wrong from a VFS
standpoint, then that filesystem is broken - regardless of whether the
filesystem maintainer agrees or not. Because the VFS layer requirements
trump any low-level filesystem issues.
But perhaps more importantly (and it's the reason even _I_ don't have the
right, regardless of how high up in the maintainership chain I am), nobody
has veto-power over anything. That's to keep people honest: nobody should
_ever_ think that they are "in control", and that nobody else can replace
them.
In other words: maintainership is not ownership. It's a stewardship.
End result: maintainership is a nasty and mostly unthankful job. It doesn't
really give many privileges, and most of what it does is just have people
complain to you about bugs. The satisfaction is there, of course, but
And finally: maintainership is largely about working with people. There's
some code in there too, but people tend to be more important.
James also replied to Justin, reiterating the point that maintainership was not
the same as ownership, and saying, "It's not about control, it's about
co-operation. The control you seek simply does not exist in the kernel
development process." He also pointed out specifically, that Justin had invited
him to integrate his patches whenever he pleased; and that James couldn't be
held responsible for accepting that invitation. Justin replied, saying that
he'd given James a lot of information to help decide which changes to
integrate, and that James had ignored that data, causing harm to the driver.
But the debate didn't go on very long, and petered out quickly without real
resolution.
7. ReiserFS Support For laptop_mode
16 Jan - 22 Jan (5 posts) Archive Link: "[patch] reiserfs support for
laptop_mode"
Topics: FS: ReiserFS, FS: ext3, Power Management: ACPI
People: Micha Feigin, Nikita Danilov, Bart Samwel
Micha Feigin said:
I've been using this since 2.4.22 and since laptop_mode is in the kernel
since 2.4.23-pre<something> and I haven't seen that anyone else has
implemented this so I decided to post it on the list in case anyone is
interested.
It's a patch to modify the journal flush time of reiserfs to support
laptop_mode (same functionality as ext3 has already).
Nikita Danilov replied, "Support for reiserfs laptop mode is in 2.6 now. It is
done by adding new mount option "commit=N" that sets commit interval in
seconds." Micha defended his approach, and a couple posts down the line Bart
Samwel remarked, "You might want to take a look at Hugang's patch to support
laptop mode on reiserfs in 2.6. This patch was posted somewhere last month. It
adds a "commit=" option to reiserfs, so that you can change this externally by
remounting. I think this solution is a lot cleaner than to have reiserfs code
directly depend on laptop mode." He added, "If you decide to port that patch,
you might want to look at the documentation for laptop mode in 2.6. The control
script that's in there works for both 2.4 and 2.6, and it automatically
remounts your ext3 and reiserfs filesystems with the appropriate commit options
(and remounts them without the commit options when laptop mode is stopped).
(There is also some ACPI event binding code in the documentation, which
automatically enables laptop_mode when using battery power and disables it when
your laptop is plugged in. I don't know if that works with 2.4 though.)" Nikita
replied that Hu Gang's patch had already been merged into the main tree.
8. Modular IDE For 2.6
17 Jan - 20 Jan (9 posts) Archive Link: "[PATCH] modular IDE for 2.6.1 ugly
but working fix"
Topics: Disks: IDE
People: Bartlomiej Zolnierkiewicz
Witold Krecicki posted a patch to allow IDE to be built as a module in 2.6;
Bartlomiej Zolnierkiewicz said Witold's solution would not cover every case,
and offered his own patch instead, saying, "I've been working on it from some
time and I think all cornercases are covered." Folks seemed to prefer
Bartlomiej's driver, and went on to discuss various technical issues. In one
subthread, it was made clear that the IDE module would not be unloadable once
loaded.
9. Software Suspend On PowerPC
18 Jan - 29 Jan (62 posts) Archive Link: "Help port swsusp to ppc."
Topics: Big Memory Support, Software Suspend
People: Benjamin Herrenschmidt, Nigel Cunningham
Hu Gang said he was trying to port the software suspend feature to the PowerPC,
but needed some help with the assembley code used in the function that saved
process state. Nigel Cunningham replied that he wouldn't be much use with
assembley, but that he'd help out with the other parts of the port, as Hu
progressed.
A bunch of people started debating the difficulties of the code in question,
and at some point Hu gave a link to some PPC documentation (http://soulinfo.com
/~hugang/tmp/MPCFPE_AD_R1.pdf) . At another point in the discussion, Benjamin
Herrenschmidt said:
Ok, I hammered that for a day and got pmdisk (patrick's version) suspending
and resuming on a pismo G3 (with XFree etc.. running). Lots of rough edges
still (via-pmu sleep need to be improved, ADB need porting to the new
driver model to be properly suspended/resumed, a sysdev for RTC is needed
too for time, the asm code should be fixed for G5, etc...)
I had to fix some issues in the core pmdisk code though. One big one is
that lots of drivers expect suspend to disk to be state 4 while the current
code used state 3 for that (and suspend to RAM to be state 3 btw). I hacked
that in include/linux/suspend.h, but we shall probably just get rid of
those stupid numbers and properly define each constant indstead.
We should also use a different state for the suspend calls done before
saving the image, and the ones done before resuming the image, some driver
may be optimized for these cases.
The patch is against my tree currently, and the arch/ppc/kernel/pmdisk.S
file is appended as-is (not in patch form). I don't plan to release that
right now, I may hack a bit on it in the "background" (I want to get
HIGHMEM working some day). Feel free to improve, but then keep me informed
please.
Ah, also: The "Freeing memory" phase takes forever. That should really be
fixed.
Hu confirmed that this worked on his laptop as well, as did Guido Guenther; and
the discussion continued. Several folks replied privately to Benjamin with
crash reports, "mostly lockups right after printing the number of pages to
save," and he confirmed that he'd made his system lock up under similar
conditions as well. He added, "Also, at least on pmac laptops, the HD is
usually so fast, that I suspect spending 10 seconds freeing things is less
efficient than spending this 10 seconds writing 200Mb of data to disk :) Also,
one wakup, it's quite painful to see everything be swapped in again. It may
make sense to be less agressive on the memory freeing, though finding a good
balance isn't easy." The discussion continued, and Hu soon posted a swsusp2
update of his own, saying it seemed to work fine. Nigel was happy to see this,
and said he'd add this to the main software suspend code, though marked as
experimental for the moment. There were some comments about the patch's
organization, and the thread petered out.
10. Fix For ide-scsi Crash; Some Discussion Of Whitespace Patches
18 Jan - 20 Jan (16 posts) Archive Link: "[PATCH] fix for ide-scsi crash"
Topics: Disks: IDE
People: Pascal Schmidt, Linus Torvalds, Andries Brouwer, Ben Pfaff, Andrew
Morton
Andries Brouwer posted a patch to fix an ide-scsi crash bug he'd noticed, and
Pascal Schmidt said, "I can confirm that it also makes my MO drive work with
ide-scsi. I could also successfully write 4.1 GB of data to a DVD+RW disc.
Writing 700 MB to a normal CD-RW disc also worked (yes, I know I could use
ide-cd for this, I just did this for testing the ide-scsi fix). This patch
seems to solve all my 2.6 ide-scsi problems." Linus Torvalds said, "I've
applied the fix part of it and pushed it out. If Andries wants to re-send the
whitespace fixes, I can apply those too, but I hate applying patches like this
where the whitespace fixes hide the real fix." Andries replied:
Yes, it seems we presently have no good mechanism / policy here. Patches
are noise. If some kernel version works and another doesnt, one has to look
at the diffs. Whitespace-only diffs are bad, I would never submit them.
They also needlessly invalidate existing patches.
On the other hand, nice, readable kernel sources are important. I used to
polish the immediate neighbourhood of an actual change. If that is
undesirable, what would you prefer?
Ben Pfaff remarked, "When one version of a source file works and another
doesn't, `diff -b' or `diff -w' usually does a good job of ignoring whitespace
changes." And Linus also said to Andries:
Whitespace-only diffs can be very useful. In particular, they are common
when somebody starts working on a piece of code without a maintainer, and
the old code was terminally broken wrt whitespace. Happens quite often in
the driver world.
So I don't have any real issues with applying whitespace-only patches, and
I much prefer them to patches that mix whitespace and bugfixes. In
particular, if the whitespace fixes are preparation for some other cleanup,
it's usually a good idea.
(I agree that if the whitespace fix is just random, it's usually not worth
it).
In Pascal's original reply to Andries, he'd also said that the atapi-mo-support
in Andrew Morton's tree were no longer needed, because "That patch only works
with 2048 byte sector discs, while the ide-scsi/sd solution also works with 512
and 1024 byte sector discs." Linus in his same reply, said, "I'd really like
the ATA cdrom driver to handle different sector sizes properly. There really is
no excuse for a block device driver to hardcode its blocksize if it can avoid
it." Andries said in his reply:
Yes, it is very easy to change that.
And another thing that is very easy is to move partitioning away from the
individual block devices. It was part of the stuff I did last year. Hope to
try again for 2.7.
And then there is the read-only part that must be removed.
Those are three reasons why ide-cd today doesnt work so well with optical
disks. But I am not sure it is desirable to make ide-cd work with them. The
source would be littered with ifs - all this toc stuff is inappropriate for
disks.
11. ALSA Vs. OSS Sound Support
19 Jan - 24 Jan (32 posts) Archive Link: "ALSA vs. OSS"
Topics: Ioctls, Sound: ALSA, Sound: OSS
People: Jaroslav Kysela
Markus Hastbacka asked what the difference was between ALSA and OSS sound
support; and why ALSA became the 2.6 default. He said he understood some of
ALSA's good features, but noted that it wouldn't let him open two sound sources
at the same time, such as xmms and Quake 3. Raphael Rigo couldn't answer the
larger question, but he did give a pointer to some instructions (http://
www.alsa-project.org/alsa-doc/doc-php/asoundrc.php3?company=Generic&card=
Generic&chip=Generic&module=Generic#softmix) to enable software mixing with
ALSA. Elsewhere, Jaroslav Kysela also said to Markus, "It seems that you don't
understand our goals. Please, look to our web pages - http://
www.alsa-project.org. If you use audio devices only for consumer use, you
probably don't notice anything special." Regarding opening multiple sound
sources, Jaroslav added:
We don't do this in kernel. We implemented the direct stream mixing in our
library (userspace). If your applications already uses ALSA APIs or if you
redirect the OSS ioctls to ALSA library (our aoss library), you can enjoy
multiple sounds.
Of course, using hardware which can do the hardware mixing is still better.
It's the same difference like between sw 3D rendering and hw 3D rendering.
12. Net Device Error Logging Macros For Drivers
19 Jan - 20 Jan (5 posts) Archive Link: "[PATCH 2.6.1] Net device error
logging"
Topics: Disks: SCSI
People: Jim Keniston, Andrew Morton, Alan Cox, Jeff Garzik
Jim Keniston said:
The enclosed patch implements the netdev_* error-logging macros for network
drivers. These macros have been discussed at length on the linux-kernel and
linux-netdev lists. All issues that reviewers have raised were addressed
previously. This is just an update for v2.6.1.
In December, Jeff Garzik indicated his intention to merge this into the
net-drivers-2.5-exp queue, but he apparently never got around to it. As
previously discussed, these macros are in demand now (e.g., for the e1000
driver) and have essentially no impact on drivers that don't use them.
RECAP (from previous posts):
Calls to the netdev_* macros (netdev_printk and wrappers such as
netdev_err) are intended to replace calls to printk in network device
drivers. These macros have the following characteristics:
+ The first arg is a pointer to the net_device struct.
+ The second arg, which is a NETIF_MSG_* message level, can be used to
implement verbosity control.
+ The remaining format + args are the same as in the corresponding printk
call.
+ Standard message prefixes: verbose (interface name, driver name, bus
ID) during probe, or just the interface name once the device is
registered.
+ The current implementation just calls printk. However, the netdev_*
interface and availability of the net_device pointer open the door for
logging additional information (via printk, via evlog/netlink, etc.) as
desired, with no change to driver code.
Andrew Morton replied:
Looks OK to me.
But it does make one wonder whether we'll soon see standalone patches for
scsi_printk(), pci_bridge_printk(), random_other_subsystem_printk(), ...?
Or is it intended that the backend logging code will be implemented mainly
in terms of the `struct device'? So netdev_printk() will be a bit of
netdev-specific boilerplate which then calls into a more generic
device_printk()?
Jim replied:
Well, there is indeed sdev_printk for the SCSI mid-layer and low-level
drivers. Dan Stekloff posted an updated patch for this on linux-scsi
yesterday.
When Alan Cox suggested dev_printk, it was with the idea that other
subsystems might have similar macros. Although I don't know of other such
macros in the works, I wouldn't rule them out.
He added:
I think dev_printk will work just fine for drivers where [driver name + bus
ID] is the appropriate message tag. Where that's not the case, other macros
emerge. (For example, for net devices you want the interface name, and for
SCSI devices the SCSI bus ID is more interesting than the PCI bus ID.)
Another thing to consider is whether, for the subsystem in question, some
other struct pointer (e.g., struct net_device* or struct scsi_device*)
might prove more useful in the future than the struct device pointer. I.e.,
such pointers could be used to get at the struct device AND other
subsystem-specific info.
Also, there are also situations where there is no underlying struct device
(e.g., some upper-level network drivers) or the driver is not yet defined
(e.g., during a SCSI scan).
13. Linux 2.6.1-mm5 Released
20 Jan - 22 Jan (40 posts) Archive Link: "2.6.1-mm5"
Topics: Disks: IDE, Version Control
People: Andrew Morton, Christoph Hellwig
Andrew Morton announced 2.6.1-mm5, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1/
2.6.1-mm5/
Mainly a resync
+ Various little fixes
+ Various fixes to make 2.6.1-mm5 successfully build and run with current
gcc CVS (gcc-3.5).
+ Building the IDE drivers as modules should work now.
Christoph Hellwig asked, "Any reason you keep
CardServices-compatibility-layer.patch around? Having a compat layer for old
driver around just for some architectures, thus having drivers that only
compile on some for no deeper reasons sounds like an incredibly bad idea.
Especially when that API is not used by any intree driver and only in -mm ;)"
Andrew replied:
Yes, we were concerned about avoiding breaking the various random
out-of-tree pcmcia drivers which people use. Russell would prefer that if
we _do_ have a compat layer it should be implemented in a different manner.
But we're all fairly uncertain that the compat layer is needed - converting
a driver is a pretty simple exercise, and Davd Hinds doesn't intend to
maintain his drivers into 2.6.
So the compatibility layer will probably go away soon, unless something
happens to bring it back into consideration.
14. Status Of HPT370 Under 2.4 And 2.6
20 Jan - 21 Jan (9 posts) Archive Link: "HPT370 status [2.4/2.6]"
People: Wilfried Weissmann, Brian McGroarty, Mans Rullgard, Xavier Bestel
Jan De Luyck asked how usable the Hightpoint HPT370 ide "raid" controller was
on Linux 2.4 and 2.6; Wilfried Weissmann replied, "2.4 is fine if you use the
ataraid code. mirroring is not fault tolerant so you would not want to use
that. raid-0 and jbod is ok. i am currently looking into 2.6. i will probably
write an evms plugin for the new kernel. the nice thing is that it will work
also for 2.4er kernels with the evms patches plus we get a proper mirroring
solution for free. :)" Brian McGroarty said, "No problems with 2.4 here. 2.6
recognizes my 374, which uses the hpt366 driver like the 370. However, no
devices are being made available from it (http://lkml.org/lkml/2004/1/16/18)" .
Xavier Bestel confirmed seeing the same behavior on his own system; although
Mans Rullgard reported his hpt374-based board working fine with 2.6.
15. KGDB 2.0.5
20 Jan - 21 Jan (4 posts) Archive Link: "kgdb 2.0.5"
Topics: Networking
People: Amit S. Kale
Amit S. Kale announced:
kgdb 2.0.5 is available at http://kgdb.sourceforge.net/kgdb-2/
linux-2.6.1-kgdb-2.0.5.tar.bz2
ChangeLog
2004-01-20 Amit S. Kale <[email protected]>
* Created a ring buffer for kgdb ethernet packets. Several fixes and
changes to kgdb on ethernet.
2004-01-20 TimeSys Corporation
* Fixed a problem with not responding to Ctrl+C during priting of console
messages through gdb.
I have pasted below eth.patch for review. When using the ethernet
interface, gdb times out several times. It receives packets and junk
instead of acks. I see following type of messages out of 8139too.c on the
console "eth0:Out-of-sync dirty pointer, 15 vs. 20."
16. AGPGART Preliminary SiS648 Support
20 Jan (1 post) Archive Link: "[PATCH] AGPGART preliminary SiS648 support"
People: Oliver Heilmann
Oliver Heilmann said:
Preliminary 648FX agp support.
The delay problem described in http://www.ussg.iu.edu/hypermail/linux/
kernel/0401.1/0053.html still exists. Dave: any luck with that data sheet
yet?
agp3 specifies things that had been left up to implementers in previous
versions hence the new generic-agp3.c file. Apart from the problem
described above the 648 chipset seems to stick to the spec.
If this is also true for other chipset it might be possible to turn this
into a generic agp3 driver at some point?
Obviously, users of the fglrx driver will want to turn off the internalagp
option.
17. Linux 2.6.2-rc1
20 Jan - 24 Jan (11 posts) Archive Link: "Linux 2.6.2-rc1"
Topics: Disks: SCSI
People: Linus Torvalds, Stephen Rothwell, Rusty Russell
Linus Torvalds announced 2.6.2-rc1, saying:
Ok, this is the next "big merge" with things from Andrew's -mm tree, along
with a number of new drivers and arch updates.
People have been busy little beavers. In particular, there are 432 patches
that came through Andrew.
Of the other updates, the biggest single thing is the new qla2xxx SCSI
driver. But there's a fair number of other drivers too. See the summary for
more details.
Stephen Rothwell pointed out that Linus had spelled his name wrong (Rothwel) in
the ChangeLog, and said that Rusty Russell had offered him some sage advice, to
nip that in the bud or it would haunt him forever. Linus replied:
For every time IBM removed one vowel from one of their ppc mnemonics, I'll
remove one "l" from a ppc developer.
We'll see who blinks first.
Linus "payback time" Torvalds
18. Kernel Sub-Project Mailing List Posting Policies
21 Jan - 26 Jan (64 posts) Archive Link: "Re: List 'linux-dvb' closed to
public posts"
People: Linus Torvalds, Jes Sorensen, Rik van Riel, Michael Hunold, Dave Jones
Dave Jones tried to post to the linux-dvb mailing list, which was listed in the
kernel MAINTAINERS file as the official list for DVB discussion; but since he
wasn't actually subscribed to the list, it rejected his post. He said on
linux-kernel, that these sorts of closed lists should be marked as such in the
MAINTAINERS file, so folks didn't waste their time. Linus Torvalds replied,
"Sounds like they shouldn't be in MAINTAINERS at all if they can't be posted
to. I mean, what's the point?" There was a lot of agreement with this, and Jes
Sorensen said at one point, "can a list be considered a contact point at all if
you can't post to it? If they are so afraid of outside posters, they can setup
a specific list for bug reporting only thats open or something." And Rik van
Riel said, "we should remove all addresses from MAINTAINERS where bug reports
by email aren't welcome."
One reason for keeping a list closed is to avoid spam; and the discussion
meandered into various anti-spam techniques, bayesian filtering and so forth.
At one point, Michael Hunold took it back to the linux-dvb issue, saying:
We've created a new e-mail address which is currently an open mailing-list
anybody can subscribe to.
It's currently watched by the main developers. If spam takes over the list,
we might change it to "moderated" or even route it to one single person.
Sorry for the inconvenience, I hope this is a solution we can all live
with.
He posted a patch to the MAINTAINERS file, to add
"[email protected]" as the open list, and to mark
[email protected] as subscription-only. Dave thanked him, and the thread
ended.
19. SiSFB Update For 2.6.1
21 Jan - 22 Jan (6 posts) Archive Link: "[PATCH] sisfb update 2.6.1"
Topics: Framebuffer
People: Thomas Winischhofer, Andrew Morton
Thomas Winischhofer said:
Update for SiS framebuffer driver for 2.6.1 vanilla
Since it does not seem as if the fbdev stuff gets merged anytime soon, I
made this patch for 2.6.1 vanilla.
I slightly lost track of current patch size policy, so please excuse me if
this is beyond current limits.
Anyway, sisfb is simply broken in current 2.6.x. This patch updates sisfb
to the current development version which no less than 11 months ahead of
the version in the kernel.
Updated includes
+ many fixes (duh)
+ support for new chipsets (661, 741, 760)
+ support for new video bridges (301C, 302ELV)
+ removal of all offending fp code (as discussed earlier this month)
+ a lot of code clean-up (which is the main reason for its size)
Patch is here: http://www.winischhofer.net/sis/sisfb_patch_2.6.1.diff.gz
Andrew Morton replied, "we need to coordinate this with James and Ben who are
also doing things in this area. But we wouldn't want to have to defer this SiS
patch until everything is sorted out in the fbdev core - life is too short ;)"
. Thomas replied:
Exactly. I don't see any activity on the fvdevel list since a while back.
Don't even know what the current status is.
Anyway, it required only to compiler directives to exclude the
modifications needed by the current James-stuff. Shouldn't be too hard.
20. Data-Flushing Prior To Software Suspend
21 Jan - 22 Jan (13 posts) Archive Link: "PATCH: Shutdown IDE before powering
off."
Topics: Disks: IDE, Software Suspend
People: Nigel Cunningham, Andrew Morton, John Bradford, Jeff Garzik, Bartlomiej
Zolnierkiewicz, James H. Cloos
Nigel Cunningham said, "Here's a patch Bernard Blackham posted to the Software
Suspend mailing list, which has fixed data-not-being-properly flushed issues
for some people. (Forwarded with Bernard's permission)." Andrew Morton pointed
out, "This spins down the disk(s) when you're just doing do a reboot. That's
fairly irritating and could affect reboot times if one has many disks." John
Bradford speculated, "I think it is an attempt to force some broken drives to
flush their cache, but I wonder whether it will simply move the problem from
one set of broken drives to another :-)." James H. Cloos Jr. felt that this was
exactly what would happen; and close by, Nigel asked if there were any better
way. John said, "It was discussed at length around the 2.4.20 timeframe, when
the power-off cache-flush and spin down behavior was changed, but I don't
remember any real conclusion being reached." And Andrew said:
A couple of thoughts come to mind:
a) Don't do it if the user typed reboot - only do it if we're powering
down.
b) Try to do a cache flush instead. If that fails (do we know?) then power
down the disk instead.
Nigel started to consider this, when Jeff Garzik broke in with, "I'm either
shocked or very very worried that the reboot notifier that flushes IDE in
2.4.x, ide_notifier, is nowhere to be seen in 2.6.x :( That seems like the real
problem -- the code _used_ to be there." And Bartlomiej Zolnierkiewicz said,
"Yep, it should be re-added. I wonder when/why it was removed?" But there was
no answer.
21. Linux 2.6.2-rc1-mm1 Released
22 Jan (18 posts) Archive Link: "2.6.2-rc1-mm1"
Topics: SMP
People: Andrew Morton
Andrew Morton announced Linus 2.6.2-rc1-mm1, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2-rc1/
2.6.2-rc1-mm1/
+ Nothing very exciting, just lots of random fixes.
+ The x86 gcc-3.4/gcc-3.5 support seems pretty much complete now. There
are enough fixes here to get a reasonably clean build with my .config
but a full kernel build still will need work.
+ I've uploaded patch-scripts-0.14 to
http://www.zip.com.au/~akpm/linux/patches/patch-scripts-0.14/
The main change is the addition of the new `patch-bomb' script. It uses
a little standalone SMPT client written by Bryan Henderson to mail
patches to a victim, with an optional Cc to the people who wrote each
of the patches. See docco.txt for details.
22. udev 014 Relesed
22 Jan (1 post) Archive Link: "[ANNOUNCE] udev 014 release"
Topics: FS: devfs, FS: sysfs, Hot-Plugging, Version Control
People: Greg KH
Greg KH announced:
I've released the 014 version of udev. It can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-014.tar.gz (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev-014.tar.gz)
rpms built against Red Hat FC1 are available at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-014-1.i386.rpm (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev-014-1.i386.rpm)
with the source rpm at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-014-1.src.rpm (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev-014-1.src.rpm)
udev allows users to have a dynamic /dev and provides the ability to have
persistent device names. It uses sysfs and /sbin/hotplug and runs entirely
in userspace. It requires a 2.6 kernel with CONFIG_HOTPLUG enabled to run.
Please see the udev FAQ for any questions about it:
kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ (http://www.kernel.org/
pub/linux/utils/kernel/hotplug/udev-FAQ)
For any udev vs devfs questions anyone might have, please see:
kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs)
Major changes from the 013 version:
+ speed! This version is _much_ faster than the 013 release. Thanks to
Ananth Narayan for the libsysfs changes (and udev patch) that enabled
this.
+ there's a new program called udevinfo in the extras/ directory that
helps in determining the sysfs information for a specific device. This
is useful in writing new udev rules.
+ the %D modifier is now gone. People who were using it to provide a
devfs naming scheme will need to rewrite their rules (look at the
examples on the linux-hotplug-devel mailing list for more details.)
+ lots of little changes and bug fixes.
Thanks again to everyone who has send me patches for this release, a full
list of everyone, and their changes is below.
udev development is done in a BitKeeper repository located at:
bk://linuxusb.bkbits.net/udev
Daily snapshots of udev from the BitKeeper tree can be found at:
http://www.codemonkey.org.uk/projects/bitkeeper/udev/
If anyone ever wants a tarball of the current bk tree, just email me.
23. Support For VT6410 IDE/RAID Chipset In 2.6
22 Jan - 24 Jan (6 posts) Archive Link: "vt6410 in kernel 2.6"
Topics: Disk Arrays: RAID, Disks: IDE, Disks: SCSI, Serial ATA
People: Mike Gabriel, Jeff Garzik
Mike Gabriel asked if anyone was working on support for the vt6410 IDE/RAID
chipset in Linux 2.6; he added, "there has been an attempt by via itself, but
it only suits redhat 7.2 kernels and systems, thus it is highly specific." Jeff
Garzik said that support should already be in 2.6; Mike asked for the names of
the config options, as he was unable to find them; and Jeff said,
"CONFIG_BLK_DEV_GENERIC or CONFIG_SCSI_SATA_VIA should do it." Mike asked, "i
thought these options were for SATA only. what i need is the ide-part of the
controller. is this support by these options, as well?" And Jeff said, "The
PATA part is handled by CONFIG_IDE, though drivers/ide/pci/via82cxxx.c may need
another PCI id or two. 'lspci -n' will retrieve these ids."
24. Status Of ATARAID In 2.6
22 Jan (2 posts) Archive Link: "ATARAID (replacement) in 2.6.x"
Topics: Disk Arrays: RAID
People: Nicklas Bondesson, Mike Fedyk
Nicklas Bondesson asked, "I wonder what the status is on implementing an
ataraid (replacement) in the 2.6.x kernel tree. It can be done with device
mapping, but it's still far too tactless I think." And Mike Fedyk replied,
"Many disagree. In fact it looks like MD will be merged with DM, so you might
as well start on using DM for this too."
25. PowerMac Update
22 Jan - 26 Jan (7 posts) Archive Link: "[PATCH] Big powermac update"
Topics: Code Freeze, Framebuffer
People: Benjamin Herrenschmidt
Benjamin Herrenschmidt said:
Time for a big PowerMac merge, a bunch of these things are driver updates
and machine support fixes that went in after the 2.6.0-rc code freeze, and
support for newer machines (including 32 bits support for the G5).
This is for inclusion with -mm and possible comments, currently, the 51
changesets are folded in one big patch. When it's time to merge with linus,
he'll get them as separate csets.
The full support for the G5 also need a sungem driver update currently in
davem's hands.
The full support for all recent pmacs also wants some fbdev updates that
will come separately.
Too big to be posted here (and I didn't feel like using Greg's script to
post 51 emails in burst to lkml :) so here's an URL to pick it up:
http://gate.crashing.org/~benh/big-pmac.diff
or
http://gate.crashing.org/~benh/big-pmac.diff.bz2
26. memblks Leaving The 2.6 Tree
22 Jan - 28 Jan (4 posts) Archive Link: "[PATCH] Remove memblks from the
kernel"
People: Martin J. Bligh, Matthew Dobson, Yasunori Goto, Jes Sorensen
Martin J. Bligh said:
This patch removes memblks from the kernel ... we don't use them, and the
NUMA API that was planning to use them when they were originally designed
isn't going to use them anymore. They're just unnecessary added complexity
now ... time for them to go.
There's a slight complication in that ia64 uses something with a similar
name for part of its memory layout, but Jes Sorensen kindly untangled them
from each other for us. The patch with his modifications is below. Jes
tested it on ia64, and I testbuilt it with every config in my arsenal.
Matthew Dobson said, "As the unfortunate soul who pushed this whole memblk
concept way back when, I'll add my support for their removal. The things I
envisioned happening with memblks never materialized and so Martin is right,
now they're just taking up space. Adios memblks, we barely knew ye." And
Yasunori Goto added, "I feel I have to agree removing memblk, because my
opinion is just concept and I don't have any patch yet. If memblks will be
needed again when we will be able to support partial failure of memory, I will
post the patch."
27. Linux 2.6.2-rc1.mm2 Released
23 Jan - 25 Jan (24 posts) Archive Link: "2.6.2-rc1-mm2"
Topics: Framebuffer, Power Management: ACPI
People: Andrew Morton, Thomas Winischhofer
Andrew Morton announced Linux 2.6.2-rc1-mm2, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2-rc1/
2.6.2-rc1-mm2/
+ There is a new debug check in here which drops a stack trace when a
piece of code calls one of the sleep_on() functions without lock_kernel
() held. This is almost certainly a bug. Please try to identify (from
the trace) which subsystem is the culprit and copy its maintainer when
reporting such traces.
After ten such warnings the diagnostic shuts itself up.
+ A big SiS framebuffer driver update. Please test, and include Thomas
Winischhofer <[email protected]> in any reports.
+ Included the latest ACPI test tree. Please copy
[email protected] on any ACPI-related reports.
+ Another MD update.
28. Exporting Kernel Headers To User-Space; Stablizing The Kernel ABI
23 Jan - 25 Jan (10 posts) Archive Link: "Userland headers available"
Topics: Kernel Build System, Klibc, Version Control
People: Mariusz Mazur, Daniel Jacobowitz, H. Peter Anvin, Sam Ravnborg
Mariusz Mazur said, "At http://ep09.pld-linux.org/~mmazur/glibc-kernel-headers/
there are userland headers for linux, derived from 2.6 kernels with lots of 2.4
compatibility fixes. CVS repo can be found at cvs.pld-linux.org/
glibc-kernel-headers (anon and webcvs). These headers are currently used to
compile a whole linux distro (ftp.pld-linux.org/dists/ac) for x86, sparc,
amd64, alpha and ppc, but general fixes are applied to all archs since we never
know if a new arch won't be added (amd64 was added just a month-two ago). #1
feature is that they are and will be maintained (currently three people are
working on them) and bugs are mostly fixed instantly." Daniel Jacobowitz
replied:
I've done precisely the same thing for Debian - if I find the time, I'll
compare...
I would really like to come up with an approach to maintain this interface
definition in the kernel source. I'm still trying to think of a way to do
it without breaking compatibility or kernel builds.
Mariusz replied, "As I really would like that (less work for me :) I do not
think this is possible. First thing - 2.4 compatibility in 2.6 kernel would
seem weird to say at least. Second - I've ripped out kernel code where I could
and used glibc includes instead - this is (a) The Right Thing (tm) and (b)
practically undoable inside kernel or would require huge amounts of work, which
is really better of left outside."
Sam Ravnborg also replied to Daniel's suggestion, offering to help with any
kbuild needs that might come up. Elsewhere, H. Peter Anvin also said:
We've referred to this for quite a while as the "ABI header project"; it's
been targetted for 2.7, since it missed the 2.6 freeze.
We have set up a mailing list at:
http://zytor.com/mailman/listinfo/linuxabi
The goal is to get a formal exportable version of the kernel ABI that
user-space libraries can use.
Daniel checked out the list, but noticed that there had never been any traffic
on it. He asked what was up, and H. Peter replied, "There was some traffic on
the klibc list, but I don't think things got started after the new list was
created."
29. Linux 2.4.25-pre7 Released; Status Of 2.4 Deep Freeze
23 Jan - 27 Jan (16 posts) Archive Link: "Linux 2.4.25-pre7"
Topics: Disks: IDE, FS: FAT, FS: JFS, FS: XFS, FS: sysfs
People: Marcelo Tosatti, Rusty Russell, Udo A. Steinberg
Marcelo Tosatti announced Linux 2.4.25-pre7, saying:
It contains a bunch of architecture-specific updates (ia64, ppc, mips), JFS
and XFS updates, bugfix for big (>128GB) FAT filesystem corruption, amongst
others.
About 2.4 freeze:
The planned freeze during 2.4.26 can happen only for 2.4.27.
There are a few bad problems I'm aware of which still need to be fixed
(aic7xxx needs to be updated, modular IDE has some problems, etc). Those
should get fixed during 2.4.26-pre.
Udo A. Steinberg asked if Marcelo planned to merge cryptoloop into the kernel
before the freeze, and Marcelo replied that no, he had not plans to do so.
Rusty Russell asked:
Any chance of the forward-compatible module_param patch?
Name: 2.4 module_param Forward Compatibility Macros
Author: Rusty Russell
Status: Tested on 2.5.24-pre6
Version: 2.4
D: Simple uses of module_param() (implemented in 2.6) can be mapped
D: onto the old MODULE_PARM macros.
D:
D: New code should use module_param() because:
D: 1) Types are checked,
D: 2) Existence of parameters are checked,
D: 3) Customized types are possible [1]
D: 4) Customized set/get routines are possible [1]
D: 5) Parameters appear as boot params with prefix "<modname>." [1]
D: 6) Optional viewing and control through sysfs [2]
D:
D: [1] Not for 2.4 compatibility macros
D: [2] Not in 2.6.1 or 2.4, and only if third arg non-zero.
Marcelo said yes, he'd apply the patch.
30. IrDA Serial Dongle Support In 2.6 Reaching Parity With 2.4 Support
23 Jan - 26 Jan (3 posts) Archive Link: "New IrDA drivers for 2.6.X"
People: Jean Tourrilhes, David S. Miller
Jean Tourrilhes said:
Martin Diehl has finished converting all the old style dongle driver to the
new API. This was the last major feature parity issue with 2.4.X, with this
work, 2.6.X should support all the IrDA serial dongles that 2.4.X supports.
Martin also did a few other cleanups and fixed tekram-sir so that it works
with real hardware.
All patches depend on the first patch, and the last patch depend on the
previous patches. I tested this on 2.6.2-rc1 with an actisys dongle,
neither Martin or I have hardware to test the other dongle drivers.
David S. Miller said, "All applied. I'll queue this up. I'll try to get it in
now but it may be deferred to the next 2.6.x release." Jean thanked him, and
the thread ended.
31. Status Of ext3 In 2.2 Kernels
23 Jan - 28 Jan (8 posts) Archive Link: "2.2 kernel and ext3 filesystems"
Topics: FS: ext3
People: Andrew Morton, Theodore Ts'o
Chuck Campbell asked if ext3 had ever been back-ported to the 2.2 kernel, and
Andrew Morton replied, "It was written for 2.2, and then forward-ported." He
gave a link to a patch (ftp://ftp.kernel.org/pub/linux/kernel/people/sct/ext3/
v2.2/) . Chuck was perplexed by this, as he saw no evidence of ext3 in any 2.2
kernel he looked at. Andrew explained, "ext3 was originally written for 2.2 but
was never merged into the mainstream kernel. That happened in 2.4.15." And
Theodore Ts'o remarked at this point, "There were also some bug fixes that I'm
pretty sure were never backported into the 2.2 tree...."
32. Forcedeth Update For 2.4; Some Developer Confusion
24 Jan (14 posts) Archive Link: "[PATCH] [2.4] forcedeth network driver"
People: Carl-Daniel Hailfinger, Manfred Spraul, Jeff Garzik
Carl-Daniel Hailfinger said:
attached is the current version of forcedeth, a network driver for nForce
{,2,3} chipsets which are fairly common today. So far, the only support for
nForce chipsets has been a binary-only driver from NVidia.
This driver has received testing by over 200 people on nForce1, nForce2 and
nForce3 chipsets and has already been integrated into 2.6. Before that, it
has been in -mm for a few weeks. We currently don't have any unresolved bug
reports.
Credits for the driver go to:
Andrew de Quincey: Writing a spec for the chipset
Carl-Daniel Hailfinger: Co-author of the spec, driver fixes
Manfred Spraul: Writing the driver
Jeff Garzik had some criticism, saying the patch was not ready for inclusion
quite yet; and that he should have been consulted. Carl-Daniel replied, "sorry.
Since I had not seen any net driver patches getting into 2.4.25-pre, I assumed
you had set your priorities to 2.6. Looking again, it seems the switch from
2.4.24-pre to 2.4.25-pre confused me and I forgot to double check with the
actual prepatches." He promised to do a better job at coordination, to avoid
toe-stepping.
33. Linux 2.6.2-rc1-mm3 Released
24 Jan - 26 Jan (3 posts) Archive Link: "2.6.2-rc1-mm3"
Topics: Version Control
People: Andrew Morton, Tim Cambrant
Andrew Morton announced 2.6.2-rc1-mm3, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2-rc1/
2.6.2-rc1-mm3/
+ 2.6.2-rc1-mm3's allyesconfig now successfully builds with current
gcc-3.5 CVS. However allyesconfig doesn't link because of symbol
clashes in IRDA.
+ Various random fixes.
Tim Cambrant leapt for joy, as Andrew's release included Tim's patches for the
first time ever; and Tim was super happy to get code into the kernel, a
long-time dream of his.
34. IMQ Forward-Ported To 2.6; Inclusion Still In Question
25 Jan - 26 Jan (15 posts) Archive Link: "[RFC/PATCH] IMQ port to 2.6"
Topics: Networking
People: Patrick McHardy, Vladimir B. Savkin, Tomas Szepe, David S. Miller
Marcel Sebek said he'd ported the IMQ driver (http://trash.net/~kaber/imq/)
from 2.4 to 2.6; David S. Miller asked Patrick McHardy if it was OK if David
merged this patch into his tree; but Patrick replied, "Please don't. The imq
device is buggy, it crashes when used for ingress and egress at the same time,
additionally it's unmaintained since one or two years. The lartc list is full
of bugreports. Some users that depend on the functionality are working on a
better implementation, I'd suggest to wait until then." David said he'd hold
off, in that case.
Elsewhere, Tomas Szepe said he hoped IMQ would get into the kernel at last; but
someone said there didn't seem to be much use for that code, really. Vladimir
B. Savkin offered, "Think multiple clients connected via PPP. I want to shape
traffic, so ingress is out of question. I want different clients in a same htb
class, so using qdisc on each ppp interface is out of question. It seems to me
that IMQ is the only way to achieve my goals." There followed a technical
argument over proper networking practices; and the thread petered out.
35. Cooperative Linux: Running Linux Under Windows And Other Systems
25 Jan - 29 Jan (21 posts) Archive Link: "[ANNOUNCE] Cooperative Linux"
Topics: Disks: SCSI, Hot-Plugging, Kexec, Microkernels: Adeos, Networking,
Ottawa Linux Symposium, SMP, User-Mode Linux, Virtual Memory
People: Dan Aloni, Karim Yaghmour, Nuno Silva, Rik van Riel
Dan Aloni announced:
Cooperative Linux is a port of the Linux kernel which allows it to run
cooperatively under other operating systems in ring0 without hardware
emulation, based on very minimal changes in the architecture dependent code
and almost no changes in functionality.
The bottom line is that it allows us to run Linux on an unmodified Windows
2000/XP system in a practical way (the user just launches an app), and it
may eventually bring Linux to a large sector of desktop computer users who
wouldn't even care about trying to install a dual boot system or boot a
Linux live CD (like Knoppix).
Screen-shots and further details at:
http://www.colinux.org
Our motto is:
"If Linux runs on every architecture, why should another operating
system be in its way?"
coLinux is similar to plex86 in a way that it implements a Linux-specific
lightweight VM with I/O virtualization. However, it is designed to be
mostly host-OS independent, so that with minimal porting efforts it would
be possible to run it under Solaris, Linux itself, or any operating system
that supports loading kernel drivers, under any architecture that uses an
MMU. Unlike other virtualization methods, it doesn't base its
implementation on exceptions that are caused by instructions.
Cooperative Linux is like the kernel mode equivalent of User Mode Linux. It
relies on the host OS kernel-space interfaces rather than relying on host
OS user-space interfaces.
Currently, it is stable enough (on some common hardware configurations) for
running a fully functional KNOPPIX/Debian system on Windows (see website
screen-shots).
Another project close to achieving that goal is the Windows port of User
Mode Linux (http://umlwin32.sf.net).
Project page:
http://sourceforge.net/projects/colinux
Thank you for your time,
- The coLinux development team.
This Open Source project is sponsored and produced by AIST, 2004 http://
www.aist.go.jp/
Karim Yaghmour was very excited to see this work, and suggested checking out
the Adeos Nanokernel (http://www.opersys.com/adeos/index.html) , which tried to
solve similar problems.
Nuno Silva was also enthusiastic, asking if it would be possible to run
multiple instances of Linux at the same time using this system; and also asking
if Linux could host the process itself yet. Dan replied that yes, multiple
instances were indeed possible; and as for running under Linux itself, Dan
said, "I can't say exactly when, but several people volunteered to work on
this." Karim replied:
BTW, I've been looking at the code. Many of the tricks done for forcing NT
to share resources with Linux should be unnecessary for a Linux setup.
Also, the code apparently assumes only two OSes. You probably want to check
the detailed discussion I had written some time ago about how to easily
obtain an SMP cluster with Linux (N instances on separate CPUs with very
few code modifications required):
http://www.opersys.com/adeos/dox/practical-smp-clusters/
practical-smp-clusters.html
Some of the code you've already written can be used as-is to this end. The
nanokernel side still needs some extending, but you've brought things one
step closer to completion.
On a UP system, instead of running just 2 instances, you can load a
nanokernel in a fixed RAM region and remap it in every instance's virtual
memory. You can then use a slightly modified kexec to start independent
images in different RAM regions. I had discussed this with Eric at the last
OLS and he was interested. The added advantage with Adeos is that you could
then share a single interrupt pipeline among all OSes, and have different
OSes manage different hardware components. Of course, if you add the PCI
allocation code I cover in the above paper, you can then have things like
two kernels independently managing, for example, two seperate sets of
ethernet card and SCSI disk. There's some pretty cool stuff to be done
here, away from the simple virtual devices. You could also have a virtual
ethernet layer which is shared by all OS images, and then have a private
network between all OS instances. With Adeos, you can also have one kernel
take care of all hard-rt operations and another kernel take care of the
soft-rt operations. All of it is fairly hardware independent.
Dan said, "allowing Cooperative Linux to directly access the hardware is
problematic on systems like Windows. coLinux's goal is more focused on bringing
Linux to other operating systems than resources sharing among several operating
systems. However, I have no doubt it can be used to run several virtual Linux's
on a single SMP Linux machine, with emphasis on the 'virtual'."
Elsewhere, someone else asked about possibly writing a bare-bones OS whose only
purpose was to run instances of other OSes like Cooperative Linux on top of it.
Rik van Riel suggested that it would be better just to run Linux below
everything, in order to have access to all the existing device drivers. Karim
also said that the whole bare-bones OS concept was already an integral part of
the Adeos project. Nuno Silva also gave a pointer to the xen project (http://
www.cl.cam.ac.uk/Research/SRG/netos/xen/) ; to which Karim replied, "For a UP
system, Xen may be fine, depending on what you're trying to do. If you're
looking for a better VMware, then Xen is likely to fit your bill. However,
there are a few things to keep in mind when looking at this sort of stuff. So,
for example, Xen assumes that all OSes are going to use the same devices for I/
O: same disk, same NIC, etc. It therefore implements lots of virtual devices
for these. But what if you wanted each OS to manage separate hardware? Also,
I'm not sure I want my OS instances to have to request memory on a page basis
with the nanokernel/monitor. Wouldn't it be just better to reuse the existing
work on the hotplug hardware (hotplug CPU, hotplug memory, etc.) to have the
kernels get/return hardware resources to the nanokernel? Also, how generic is
the virtualization solution being examined? I've put some thought into getting
a virtualization architecture which spans UP, SMP, SMP-clusters, and hard-rt,
and wrote that down as a series of papers about Adeos. I probably don't have
the final answer, and there are probably many things I haven't figured out in
the papers I've written on the topic, but you may want to take a look."
36. drivers/net/de6* Needs A Maintainer
25 Jan (2 posts) Archive Link: "Request for new maintainer"
People: Bjorn Ekwall, David S. Miller
Bjorn Ekwall said:
Due to frequent travels and lost hardware I can't even pretend to maintain
the drivers for the parallel port network adapters D-Link de600 and de620
any more ( drivers/net/de6* ).
I am deeply thankful to the people who have added patches that allowed
these OLD drivers to live on. We're talking about more than TEN YEARS since
they were initially created... Scary...
If anyone still has access to these adapters and is willing to take the
responsibility for keeping the drivers alive, just announce the take-over,
tell me, and receive my blessings.
Lastly, I include a patch that updates my contact info. I don't even know
who to send the patch to -- that's how out of touch I am ;-)
David S. Miller accepted the patch, and asked Bjorn to send another patch if
someone else decided to take over the code.
37. perfctr 2.6.5 Released
26 Jan (1 post) Archive Link: "perfctr-2.6.5 released"
Topics: Hyperthreading, Profiling
People: Mikael Pettersson
Mikael Pettersson said:
Version 2.6.5 of perfctr, the Linux performance monitoring counters driver,
is now available at the usual place: http://www.csd.uu.se/~mikpe/linux/
perfctr/
Version 2.6.5, 2004-01-26
+ Relaxed and corrected control checks on Pentium 4:
o Allow ESCR.CPL_T1 to be non-zero when using global-mode counters on
HT processors.
o Don't require ESCR.CPL_T0 to be non-zero. CPL_T0==0b00 is safe and
potentially useful (global counters on HT).
o Require CCCR.ACTIVE_THREAD==0b11 on non-HT processors, as
documented in the IA32 Volume 3 manual. Old non-HT P4s seem to work
Ok for all four values, but this is neither guaranteed nor useful.
+ Per-process counters driver updated for filp->f_mapping change in
2.6.2-rc kernels.
+ Support 2.4.21-9.EL (RHEL3) and 2.4.22-1.2149.nptl (FC1) kernels.
+ Library updates for PowerPC:
o Added cpu_type constants for struct perfctr_info.
o Decode PVR and define perfctr_info.cpu_type accordingly.
o Added event set descriptions for 604/604e/750.
38. FUSE 1.1-pre2 Released
27 Jan (1 post) Archive Link: "[ANNOUNCE] FUSE 1.1-pre2"
Topics: FS: NFS
People: Miklos Szeredi
Miklos Szeredi said:
This is the next (and hopefully the last) prerelease version to 1.1.
The biggest change is that NFS export of a FUSE filesystem is now supported
under linux 2.6.X. Since 2.4 has an inferior NFS export interface it would
be much more difficult to support it. But who wants to use 2.4 anyway :)
The other change is that small (4k) reads are now the default again. This
is because there is some overhead with 64k reads (a memory allocation and
an extra memory copy). Of course if your filesystem handles big reads more
efficiently, then 64k reads may come out better. This can be controlled
with the '-l' option of fusermount, passed to the fuse_mount() function or
if using fuse_main() this also works:
fuseprog /mnt/xyz -- -l
You can download it from here:
http://sourceforge.net/project/showfiles.php?group_id=21636&package_id=
31956&release_id=212701
Please test this release, as this will be 1.1 if no problems are found!
39. ALSA 1.0.2 Released
27 Jan (2 posts) Archive Link: "[PATCH] ALSA 1.0.2"
Topics: Sound: ALSA
People: Jaroslav Kysela
Jaroslav Kysela gave a link to an ALSA patch (ftp://ftp.alsa-project.org/pub/
kernel-patches/alsa-bk-2004-01-27.patch.gz) that would "update the ALSA in
kernel to version 1.0.2. I am not sure, if this request is too late for 2.6.2.
If so, please, consider merging to 2.6.3." Someone else replied, saying that
users experiencing problems with the Intel8x0 driver, Jaroslav's patch seemed
to have fixed them.
40. Binary-Only Nvidia Drivers For 2.6
27 Jan - 28 Jan (7 posts) Archive Link: "Official NVIDIA drivers for 2.6"
People: Con Kolivas, Panagiotis Papadakos
Con Kolivas said:
For those who've sold their GPL soul to use the binary drivers from
NVIDIA...
NVIDIA have announced a new release of their graphic card drivers: version
'1.0-5336'
http://www.nvidia.com/object/linux.html
This release has support for Linux 2.6 kernels, fixes AGP failures on some
VIA motherboards, and fixes a problem that prevented X from running on
Samsung X10 laptops.
Voicu Liviu asked about ATI support under 2.6; and Panagiotis Papadakos
replied, "Yep there is already support in 3.7.0; Look at http://www.rage3d.net/
board/forumdisplay.php?s=&forumid=61" .
We Hope You Enjoy Kernel Traffic
Kernel Traffic is hosted by the generous folks at Tux.Org. All pages on this
site are copyright their original authors, and distributed under the terms of
the GNU General Public License, version 2.0.