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.

Pat Gefre posted his latest set of Altix patches 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.

Andrew Morton announced 2.6.1-mm4, saying:

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? ;)

Amit S. Kale said:

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.

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 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:

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.

Micha Feigin said:

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.

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.

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. At another point in the discussion, Benjamin Herrenschmidt said:

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.

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:

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:

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:

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 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:

Jim Keniston said:

Andrew Morton replied:

Jim replied:

He added:

Andrew Morton announced 2.6.1-mm5, saying:

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:

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.

Amit S. Kale announced:

Oliver Heilmann said:

Linus Torvalds announced 2.6.2-rc1, saying:

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:

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:

He posted a patch to the MAINTAINERS file, to add "linux-dvb-maintainer@linuxtv.org" as the open list, and to mark linux-dvb@linuxtv.org as subscription-only. Dave thanked him, and the thread ended.

Thomas Winischhofer said:

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:

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:

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.

Andrew Morton announced Linus 2.6.2-rc1-mm1, saying:

Greg KH announced:

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.

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.

Benjamin Herrenschmidt said:

Martin J. Bligh said:

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.

Andrew Morton announced Linux 2.6.2-rc1-mm2, saying:

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:

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:

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.

Marcelo Tosatti announced Linux 2.4.25-pre7, saying:

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:

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.

Jean Tourrilhes said:

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.

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. 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....

Carl-Daniel Hailfinger said:

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.

Andrew Morton announced 2.6.2-rc1-mm3, saying:

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.

Marcel Sebek said he'd ported the IMQ driver 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.

Dan Aloni announced:

Karim Yaghmour was very excited to see this work, and suggested checking out the Adeos Nanokernel, 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:

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; 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.

Bjorn Ekwall said:

David S. Miller accepted the patch, and asked Bjorn to send another patch if someone else decided to take over the code.

Mikael Pettersson said:

Miklos Szeredi said:

Jaroslav Kysela gave a link to an ALSA patch 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.

Con Kolivas said:

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.