Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Kernel Traffic #22 For 9 Jun 1999

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1309 posts in 5112K.

There were 483 different contributors. 197 posted more than once. 129 posted last week too.

The top posters of the week were:

1. S3 Framebuffer Successes

18 May 1999 - 6 Jun 1999 (24 posts) Subject: "S3 Frame Buffer"

Topics: Framebuffer

People: Alan CoxMatthew Kirkwood

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.

2. TGA Framebuffer Partial Success

22 May 1999 - 30 May 1999 (8 posts) Subject: "[PATCH] New TGA Framebuffer Driver (1.11)"

Topics: Framebuffer

People: Tim WaughAaron Tiensivu

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.

3. PCMCIA Implementation Debate

23 May 1999 - 8 Jun 1999 (147 posts) Subject: "2.3 wish: integrate pcmcia into mainstream kernel"

Topics: BSD, Disks: IDE, Hot-Plugging, PCI, USB

People: Pavel MachekLinus TorvaldsDavid HindsMartin Mares

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:

Installing from a IDE CDROM is very reliable. But you have to know the magic incantations for it to work:

Do you see? Even _I_ had trouble installing Linux, and I hung my machine about three times just because a standard install got confused.

If I have trouble installing Linux, something is wrong. Very wrong.

And none of these problems would have happened if cardbus support had just been part of the standard kernel.

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.

4. /dev/cua* Obsolescence

27 May 1999 - 5 Jun 1999 (15 posts) Subject: "serial callout devices"

People: Theodore Y. Ts'o

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

5. ELF Capabilities Working

27 May 1999 - 30 May 1999 (13 posts) Subject: "[PATCH]: alternative security - special gids"

Topics: Executable File Format, FS: ext2

People: Pavel Machek

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 Issue #15, Section #2  (31 Mar 1999: Journalling And 'Capabilities' In ext3) . Since then, there has been a fairly constant development of ELF capabilities. Apparently it's now getting usable.

6. Linus Still Prefers gcc To egcs

27 May 1999 - 30 May 1999 (5 posts) Subject: "linux-2.3.4pre1: Adjustments for using gcc builtins"

Topics: Compiler

People: Linus TorvaldsHorst von Brand

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:

The gcc "builtins" are generally noticeably worse than the kernel headers.

Anyway, there is a really simple choice when it comes to compilers: we will choose the one that generates better code. For a long time it _seemed_ that egcs would be the choice, but if we have to disable the new alias code and/or use ugly tricks like the above then the choice is fairly clear - gcc-2.7.2 will still continue to generate better code.

I've asked the egcs people to give us some way to tell the compiler what's going on, but at least so far I haven't had any replies. As I know how gcc-2.7.2 can be made to generate the code I want, and nobody so far has told me how to get egcs to do the same, I know which compiler _I_ will recommend.

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:

I was very excited about the alias code.

I am very NON-excited about the fact that so far NOBODY from the egcs team has indicated that there is any reasonable way to tell the compiler _not_ to do that. We're up sh*t creek without a paddle.

Anybody who suggests that a kernel should be written in all ANSI C and only according to the standards I can only shake my head at. I'm not interested. I'll continue to use an older compiler that I can at least make do what I want.

Remember: a compiler is a TOOL. If that tool is "improved" to the point where it no longer does what the user originally expected, why should it be used. I'm all for improvements, but right now there doesn't seem to be any reasonable way to tell gcc about aliases.

Don't tell me about unions. I know about unions, and the resulting source code would be so ugly as to be unreadable.

7. Tracking A Very Elusive Hang (<=2.2.9)

29 May 1999 - 2 Jun 1999 (20 posts) Subject: "2.2.9 hangs in truncate_inode_pages"

Topics: FS

People: Alan CoxLinus Torvalds

Alan Cox reported:

I've been chasing a hang in 2.2.9* and it comes down to truncate_inode_pages.

Now there are two things that have me wondering here and one cleanup item

  1. wait_on_page uses schedule() and not the SCHED_YIELD stuff so there is no guarantee another person locking the page gets run if their lock isnt going to be cleared by tq_disk
  2. __wait_on_page says you are supposed to own the page before waiting on it (ie up page->count). I don't see where we do that. We even go back to the start to allow for the pages on the inode changing if we sleep but we don't up the count ourselves.
  3. (minor) in truncate_inode_pages we do if(PageLocked(..)) wait_on_page. If we know the page is locked shouldn't we do __wait_on_page()

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.

8. Accessing The Raw Disk

30 May 1999 - 2 Jun 1999 (5 posts) Subject: "accessing raw disk."

People: Stephen C. Tweedie

Lamar Williams wanted to access a raw disk, and Stephen C. Tweedie pointed to his patch.

9. New S3 Videocard

30 May 1999 - 1 Jun 1999 (5 posts) Subject: "New S3 videocard"

People: Ian EureAnthony BarbachanStanislav V. Voronyi

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.

10. I2O Status

30 May 1999 - 31 May 1999 (8 posts) Subject: "I2O status and Linux?"

Topics: I2O

People: Alan CoxH. Peter Anvin

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

11. 2.2.x Bug Fix

31 May 1999 - 5 Jun 1999 (7 posts) Subject: "Linux 2.2.* remote exploit fix"

People: Alan CoxDavid S. Miller

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.

12. Listing Valid Kernel Parameters

1 Jun 1999 - 2 Jun 1999 (9 posts) Subject: "[PATCH] New documentation"

People: Riley Williams

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.

13. User-mode Kernel Port

2 Jun 1999 - 3 Jun 1999 (8 posts) Subject: "A user-mode kernel implementation"

Topics: User-Mode Linux

People: Oliver XymoronPavel MachekJeff Dike

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

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.

14. AFS For Linux?

4 Jun 1999 (5 posts) Subject: "AIX fs for Linux"

Topics: FS: XFS

People: Matti AarnioJeff Garzik

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.

15. Merced

5 Jun 1999 (9 posts) Subject: "EPIC"

People: David S. MillerMatti Aarnio

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... :-)"







Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.