A lot of people reported success with the frame buffer patch, and Matthew Kirkwood gave a pointer to it's home page. Juan Antonio Martinez suggested getting it into the main kernel tree. Alan Cox wasn't sure it was ready, but Matthew disagreed, and there followed a discussion about implementation and extension.

Martin Lucina reported that his latest TGA Framebuffer patch fixed all the outstanding issues he knew about, and was almost ready for inclusion in the main kernel tree (he mentioned that his alpha-memmove patch was also in the same directory). Aaron Tiensivu was extremely impressed, and reported that his WonderMultia was now quite fast, whereas before it had always been pathetically slow.

Tim Waugh felt the patches had problems, and posted an exploit to cause characters to change during redraws. He posted his own patch to fix it.

Pavel Machek wanted PCMCIA in the main kernel, saying, Having pcmcia support outside of standard kernel makes pcmcia drivers second-class citizens, which only work sometimes. I do not think that pcmcia package is developing so fast that it could not be integrated into mainstream. And, btw, mainstream kernels need support for hotplug, anyway, see hotpluggable PCI and USB..

Linus Torvalds replied, I would wish to have at least cardbus support in the default kernel, and eventually it will have to be written - the external pcmcia support indeed relegates it to second-class citizen support. And cardbus is much better done and defined than the original pcmcia anyway, and is what all modern laptops use. But he added, However, I'm not going to just use the pcmcia code as-is, as David Hinds has never been very excited about putting the support in the kernel. And I do believe that for the old-style pcmcia stuff the current approach is the right one anyway due to the ugly details. But if somebody were to start up a cardbus driver system, I wouldn't be unhappy...

David Hinds was a bit hurt by Linus' post, saying, I think this is the first time I've ever heard you express interest in kernel support for dynamically configured devices. I'm somewhat unhappy that it sounds like you're encouraging someone else to do it differently. Linus replied, The issue is one of copyrights - I've heard noises from you where you very pretty much against any tighter kernel integration. And if there is one thing I _never_ want to do, that one thing is to use somebody elses code if that somebody else is not convinced that he wants the code to be used. He added, Even if the copyright _allows_ me to use other peoples code, I always want to be extra sure that it's not just about being legally allowed, it's also about being Ok on a personal level. I've gotten the feeling that you wouldn't have wanted that..

The discussion ranged over several points, with each post participating in different threadlets; so it'll have to be described piece-meal, nonchronologically, and incompletely.

To sum up one disagreement, Pavel on his side believed that keeping PCMCIA out of the kernel would make it more difficult to keep current; while David (though not totally opposed to putting PCMCIA in the main kernel) argued that that was a negligible difference, and PCMCIA didn't suffer from those problems as much as other drivers that were in the standard kernel.

One brief threadlet began when Pavel pointed out that Martin Mares and someone else wanted to do a complete rewrite of buses for 2.3; David said he was very interested in that, but Martin hadn't been responsive to his queries; and Martin replied that he'd been very busy and would post a summary of his ideas later that week.

Another threadlet also began when Pavel pointed out that the PCMCIA drivers were actually licensed under the Mozilla Public License. He suggested releasing it under a dual license (MPL and GPL) in the future, and Linus replied, as far as I'm concerned that would be the perfect scenario. And it's certainly possible, as long as all current copyright holders agree on it. He added, We've had other projects with dual copyrights - drivers shared between Linux and BSD, so this wouldn't even be anything really surprising or new.

Linus started a threadlet in which he felt that the main problem with keeping PCMCIA out of the kernel was not the difficulty of keeping it uptodate, but the extra complexity and infrastructure that it entailed. But he added that this makes sense for PCMCIA to some degree, because PCMCIA has all the silly rules and can often need extensive help from user space in the form of configuration information. But doesn't really make much sense for cardbus (and thus all modern laptops) that is a pretty clean architecture and wouldn't really need some of the extra code.

David replied, I think you're overestimating the gap between PCMCIA and CardBus a bit. The funny IO and memory configuration stuff for PCMCIA is really not that hard to get right, and is reasonably stable and solid. Once devices are configured, PCMCIA and CardBus are roughly equally easy to deal with. But CardBus bridges are nontrivial to configure correctly from scratch. It is still not uncommon for laptops to require vendor specific Windows drivers to support CardBus... meaning that the BIOS cannot be relied on to just set everything up correctly. Later he added, The *only* strong argument I've heard for putting PCMCIA in the kernel from the standpoint of *functionality* is that in systems that are severely memory constrained, the overhead of an initrd image can be unacceptable.

One of the biggest threadlets came out of an example, posted by Linus, of installing Linux from an IDE PCMCIA CD-ROM. He described the procedure:

David wasn't convinced, and pointed out that only a very small minority of machines can boot IDE PCMCIA CD-ROM devices. Elsewhere, he added, If you can boot from this PCMCIA device (which is a platform specific feature, and not something you should necessarily expect to be able to do), then you can load an initrd image from it. So the issue reverts to the distribution maintainers' choice of supported installation modes. Elsewhere, he also said, Having looked at the configuration tables for a couple dozen PCMCIA IDE cards, I can almost guarantee that no BIOS could get it right every time. And there are some that just don't work with the Linux IDE driver at all.

Elsewhere, Linus finally broke through, with, obviously it seems to be really painful for people to try to cram in all the PCMCIA tools on a initrd disk on a CD. At least nobody does it: it seems to expand the size of the required tools enough that both SuSE and RedHat require that Linux be able to read a floppy. Which you currently can't do if the floppy is connected through a PCMCIA device.

David replied, Finally, a technical issue that is not a strawman!! Linus, why didn't you start out by describing your problem THIS way (and maybe emailing me about it privately, since it obviously seems important to you), instead of vaguely talking around the problem, insinuating that someone else should redo PCMCIA, and telling me that my work sucks? You might have found a more receptive audience, and I would have bent over backwards to deal with it.

After some more back-and-forth (not without harsh words), a kind of mutual understanding was reached, in which David would try to accomodate some of Linus' desires. A number of other developers then discussed implementation with David.

Florian Lohoff started working on a serial multiboard driver for the Aurora Aries 8000P/16000P cards, and was wondering if callout devices were still in use (he seemed to remember they were obsoleted after 2.0).

Theodore Y. Ts'o replied, The kernel has started warning people that the cua devices are obsolete as of the 2.2 kernel. Unfortunately not all of the distributions (and I have been appropriately chastised on another list for not knowing that Debian *has* phased out use of the cua devices) have made the cua devices go away in their latest 2.2-kernel based distributions. This is unfortunate, since a large number of users may still expect that they be there. So whether you feel the need to support it is up to you, and depends on who your user/customer base is. There followed a bit of discussion about /dev/cua* versus /dev/ttyS*.

Augusto Cesar posted a patch to add a feature in the socket layer to allow nonroot users to set 2 gids, to access raw sockets or priviledged ports.

A lot of people pointed out that 2.2 handled this sort of thing and more via capabilities, and Pavel Machek gave a pointer to an ELF capabilities page.

The last time this was discussed on KT was in . Since then, there has been a fairly constant development of ELF capabilities. Apparently it's now getting usable.

Horst von Brand, as a result of the recent suggestion that the kernel not use handcrafted mem* and str* functions, but instead use the gcc builtins, posted a patch to take care of that. But he added that a lot of kernel code that used those functions, had already failed to include the header file containing the hand polished definition; so they were often falling back to the gcc builtins anyway.

Linus Torvalds replied:

Horst replied, How is using gcc builtins instead of reimplementations thereof a "ugly trick"? Sure, there are now problems with the new aliasing code: Here egcs introduces a new optimization that gives _better_ code overall. But that happens to clash with the way the kernel is written, as has happened before.

Linus said:

Alan Cox reported:

Some folks pointed out that this was not a new problem with 2.2.9, and Linus Torvalds also said, Hmm.. That [truncate_inode_pages] hasn't really changed as far as I can tell, so this must have been a long-time thing that just was exposed by something else. How sure are you that it is truncate_inode_pages()? (Or should I ask "what made you find it"?)

He went on to finger Alan's #2, saying, This may be the real offender - I think you found a real bug, and it looks extremely hard to trigger, but it looks like it has been there from the very first version.

Alan replied that he'd never seen the hang on 2.2.7, while 2.2.9 and 2.2.9ac1 were both hanging every 24-36 hours; but Thierry Danis reported that he could reproduce the lock very easily in 2.2.7ac4 and 2.2.9ac1.

A number of people tackled Thierry with questions about his set-up and how to reproduce the lock. No one came up with a fix during the thread though.

Lamar Williams wanted to access a raw disk, and Stephen C. Tweedie pointed to his ftp://ftp.uk.linux.org/pub/linux/sct/fs/raw-io/ patch.

Stanislav V. Voronyi just got ahold of the S3 Trio3D2X, and was having trouble setting it up. Ian Eure replied, The newer S3 Trio3D cards are not well supported by Linux at the moment. You will need to use the vesa fbcon driver to get any graphics at all, and unaccelerated at that. You do get a nice high-rez console though. :) Harald Koenig pointed out that the next XFree86 release would support the Trio3D, and Anthony Barbachan added that XFree86 was expected to be out in just a few weeks.

Juan Casero asked about I2O's current relationship to Linux. H. Peter Anvin and Alan Cox informed him that the I2O specs were opened up, and the driver is being actively developed. Alan added, The driver work for I2O on Linux is being supported by various vendors including Symbios Logic (now part of LSI), Boxhill, and Intel.

Alan Cox posted a fix against an exploit reported on bugtraq. There was some confirmation that it worked, and David S. Miller pointed out that it would be going into 2.2.10.

Riley Williams wrote up a list of all valid kernel parameters, sorted into dictionary order and classified by subsystem. He pointed out a number of naming inconsistancies he felt he'd discovered by creating the list. There were a number of bug reports and disagreements of his interpretations. He accepted virtually all corrections, and produced an updated list.

Jeff Dike ported the kernel to user mode (!). He gave a long explanation of implentation and installation, and folks like Pavel Machek and Oliver Xymoron were highly impressed. Oliver pointed out that the subject had come up before on linux-kernel. Jeff asked for a URL, and Oliver gave him http://www.uwsg.indiana.edu/hypermail/linux/kernel/9901.3/0842.html.

Pavel suggested that making it portable would enable any system to run Linux as a user program, but Jeff said that speed issues would make this a poor advertisement for Linux, and that in any case it would be extremely difficult to port to most systems.

Jeff Garzik pointed to this article about how IBM may be porting its AFS (Andrew FS) filesystem to Linux. Matti Aarnio pointed out that this was not on the same plane as the XFS announcement, since IBM probably wouldn't be releasing any source.

Nils Vogels was curious if Linux would be ported to the Merced. Matti Aarnio said that a port was in progress, but anyone interested in more details would have to sign an NDA; but Erik Corry gave a pointer to the IA-64 Application Developer's Architecture Guide. Matti was unimpressed, and said it was very similar to a SPARC. David S. Miller replied, If people want my own personal opinion about this chips design [...] I view it as a set of powerful core ideas (most likely from the HP camp) with several terrible hacks thrown on top (which, if not done by HP... :-)