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 #124 For 2 Jul 2001

Editor: Zack Brown

By Adam Buchbinder  and  Zack Brown

linux-kernel FAQ | subscribe to linux-kernel | linux-kernel Archives | | LxR Kernel Source Browser | All Kernels | Kernel Ports | Kernel Docs | Gary's Encyclopedia: Linux Kernel | #kernelnewbies

Table Of Contents


You may notice that some of this issue's articles were written by Adam Buchbinder, who may also collaborate with me on future issues. Anyone who is interested in doing the same is welcome to contact me. Writing Kernel Traffic is a big job. I could use a hand.

Mailing List Stats For This Week

We looked at 1318 posts in 5504K.

There were 445 different contributors. 210 posted more than once. 154 posted last week too.

The top posters of the week were:

1. Status Of EEPRO100/S Support

15 Jun 2001 - 22 Jun 2001 (4 posts) Archive Link: "EEPRO100/S support"

Summary By Zack Brown

People: J. S. PeatfieldTim Hockin

Tim Hockin asked about the EEPRO/100 S under Linux, and Kelledin Tane replied that Intel's drivers supported the card under Linux, and that they were GPLed. But J. S. Peatfield replied:

The e100 driver from intel claims to support these cards (the 100 S desktop adaptor, that is), but in fact the drivers lock up under heavy UDP load (at least they do for me in 2.2.19). It seems to only be a problem with these newer cards, the e100 is solid with older cards (and things like the 100VE which is onboard on many Easterns).

Intel are working on fixing the lockups, they thought it was related to the checksum offload though turning that off doesn't prevent the lockups. Version 1.66 is much more stable than 1.55a (1.55a would lockup after 60-80M of traffic on these cards), I'm awaiting the next version to see if they have nailed it.

The driver is not GPL (I don't know why it isn't) and doesn't support the encryption asic on baords which have it (and Intel seem unwilling to release details of this asic so others can write drivers to use it).

2. New Maintainer for Linux/PPC

17 Jun 2001 - 18 Jun 2001 (3 posts) Archive Link: "Linux/PPC maintainer changing"

Summary By Adam Buchbinder

Topics: Samba, Version Control

People: Cort DouganPaul Mackerras

Cort Dougan said:

Starting today, Paul Mackerras ([email protected]) is taking over as maintainer of the Linux/PPC 32-bit tree and will continue as the Linux/PPC 64-bit tree maintainer.

The stable and development trees (2.2 and 2.4) will be moving away from the FSMLabs ftp/rsync/BitKeeper repository to the CVS tree. Changes should continue to flow into the main tree available from

Paul followed up, "Cort has put in an enormous amount of time and effort into maintaining the PowerPC port of Linux over the past 5 or 6 years, and I for one would like to acknowledge that publicly and thank him for that. It has not always been an easy task, I know, because there are a wide range of opinions within the PPC/Linux camp and Cort has been the man on the spot to sort out the balance between the competing interests. And I for one will miss the time, effort and resources he has put into the infrastructure things such as the repository, web pages, ftp site etc." The port's home is at

3. Status Of VLAN Support

19 Jun 2001 - 22 Jun 2001 (20 posts) Archive Link: "VLAN in kernel?"

Summary By Zack Brown

Topics: Networking

People: Ben GreearDax KelsonDavid S. MillerGleb Natapov

Holger Kiehl and others had been using Ben Greear patch to support VLAN virtual networking in the 2.4 kernel. He said there had been no problems with the patch for a long time, and asked why it had not been included in the Linus tree. Ben, the author of the patch, replied:

I have had a good discussion with Dave Miller today, and there is one outstanding issue to clear up before my 802.1Q VLAN patch may be considered for acceptance into the kernel:

Should VLANs be devices or some other thing?

I strongly feel that they should be devices for many reasons.

  1. It makes integration with user-space tools (ip, ifconfig, arp...) a non-issue.
  2. It is logically correct, a VLAN is a (net_)device and in all ways acts like one.
  3. It introduces no fast-path performance degradation that I know of. The one slow path involves the linear lookup of a device by name (or id??). This can be fixed by hashing the list, if needed.
  4. Both VLAN patches have used VLANs-as-devices from the beginning, and have seen no ill affects to this approach that would be mitigated by some other architecture.

However, we need the community as a whole to agree more-or-less that my (and others who share them) arguments are sound. So please, bring your complaints fowards now...or forever patch by hand!

Also, any other complaints or suggestions for the VLAN code should be mentioned too, of course!

If you wish to view the patch, get the 1.0.1 release from my vlan page: I will release a new one shortly with the fast-dev-lookup code (which is already #ifdef'd out) completely removed, as per Dave's wish.

A bunch of people lined up in support of treating VLANs as devices, and Dax Kelson put in, "Conceptually, VLANs as network devices is a no brainer." But David S. Miller replied, "Technical implementation level concerns need to be considered as well as "does it look nice"." Gleb Natapov argued, "How can I implement intermediate layer between L3 and L2 in the current kernel? This is what VLAN is all about. The only way to do it today is to pretend to be a network device for L3, do your job (adding VLAN header) and the job of L2 (build ethernet header) and queue packet to master device for transition. This is what ipip module does, this is what bonding module does and many others. And this is because L1 and L2 coupled too tightly together in the kernel now. In fact it is almost impossible to implement new L2 protocol without changing net_device structure. Something should be done about L1+L2 design till then pretend to be the net_device is the only solution if you want VLAN to be transparent for L3 protocols. If you want to implement VLANs only for IP layer this can be done differently of course."

There was no reply, but Ben replied that treating VLAN as a device had been "the easiest way to implement things. It allowed me to not have to touch any of layer 3, and I did not have to patch any user-space program like ip or ifconfig." He added, "I'm not even sure if the nay-sayers ever had another idea, they just didn't like having lots of interfaces. Originally, there were claims of inefficiency, but it seems that other than things like 'ip' and ifconfig, there are no serious performance problems I am aware of."

4. Gearing Up For 2.5

19 Jun 2001 - 21 Jun 2001 (14 posts) Archive Link: "Linux 2.2.20-pre4"

Summary By Zack Brown

People: Alan Cox

Alan Cox announce 2.2.20-pre4 and added, "Linux 2.2 is now firmly into maintainance state. Patches for neat new ideas belong in 2.4. Generally new drivers belong in 2.4 (possibly in 2.2 as well after 2.4 shows them stable). Expect me to be very picky on changes to the core code now."

5. Behavior Changes Between 2.2 And 2.4

19 Jun 2001 - 20 Jun 2001 (12 posts) Archive Link: "2.2 PATCH: check return from copy_*_user in fs/pipe.c"

Summary By Adam Buchbinder

People: Zack WeinbergAndrew TridgellDavid S. MillerLinus Torvalds

Zack Weinberg said, "The anonymous pipe code in 2.2 does not check the return value of copy_*_user. This can lead to silent loss of data." 2.4 did not have the bug, he said, as the relevant file had been completely rewritten. He posted the patch against 2.2.18 and higher, and reported that on his machine, it had been running since May 13 with no problems.

David S. Miller recalled that Andrew Tridgell had originally spotted this problem, but for some reason that David couldn't recall, they had agreed not to fix it. Andrew replied that Linus Torvalds had made the decision. Andrew said, "Linus didn't want to fix it in pipe.c until copy_from_user was fixed on all architectures" [...] "He didn't want us to fix just this one case and then forget about fixing the general case."

Zack also replied to David, asking why the bug had been fixed in 2.4 but not 2.2; in particular he asked, "Some sort of compatibility issue?" David replied cryptically, "No, some kind of "it doesn't matter" issue." Zack disagreed, saying that the change created a situation in which user-land code would behave differently under 2.2 than 2.4; but Linus replied:

Hey, I can demonstrate user code that behaves differently depending on what compiler options were used etc.

Hint: "undefined behaviour".

If somebody passes in a bad pointer to a system call, you've just invoced the rule of "the kernel _may_ be nice to you, but the kernel might just consider you a moron and tell you it worked".

There is no "lost data" or anything else. You've screwed yourself, and you threw the data away. Don't blame the kernel.

6. Microsoft And Source Licensing

20 Jun 2001 - 22 Jun 2001 (7 posts) Archive Link: "One more ZDNet article with BillG hammering Linux and Open Source."

Summary By Zack Brown

Topics: Microsoft

People: Bill GatesGerhard MackMiles LaneAlexander Viro

Miles Lane gave a link to a Bill Gates interview in which Bill laid out his official stance on the GPL. Some folks joked about Bill saying, "I don't know that anyone has ever asked for the source code for Word. If they did, we would give it to them. But it's not a typical request." There were some "I'll take a copy, Bill" comments, until Gerhard Mack remarked, "Funny but by giving it to you they could really screw you when it comes to opensource work. If you think the GPL is viral you havn't seen "shared source".. at least the GPL only applies to derived works." And Miles said:

Here's the kicker. I went to Microsoft's site and tried to find a copy of their Shared Software License or some approximation thereof. All I found was a bunch of Craig Mundie's blathering and some critiques of the GPL:

How can we evaluate if there is any point in asking BillG for the Word source code if they won't even show us the blighted license? What I suspect is that there IS no "Shared Source License." And, even if there were, Microsoft doesn't want anyone to see it because that would allow a direct comparison with the GPL, LGPL and so on. Heaven forbid that apples should be compared to apples!

What they appear to have is a hodgepodge of different ways of "sharing" source code.

He gave a link to, which included brief descriptions of various licensing possibilities. Miles went on to give his interpretation of that page:

Microsoft figures out what rights it wants to allow each of these categories of developers/users and then incredibly restricts the freedom of anyone who sees their code to change, port or use the code in any way at all. My impression is that they are happy to have grad students look at the NT code, because they want really smart people to get used to using NT all the time and then graduate and go become Microsoft borgs.

What I imagine happens is that if you ask for source code, they decide whether they want to show it to you, then they make you sign away your life (such as freedom to work on any code vaguely like the code they're going to show you) and then they sue you into bankruptcy or out-of-court settlement if you breathe in a way they don't like.

Finally Alexander Viro said the whole subject was off topic, and the thread ended.

7. Linus Estimates 2 Weeks Before 2.5.0

21 Jun 2001 (13 posts) Archive Link: "correction: fs/buffer.c underlocking async pages"

Summary By Adam Buchbinder

People: Linus Torvalds

In the course of discussion, Linus Torvalds said about a proposed patch, "it does end up being a 2.5.x issue as far as I'm concerned (and don't worry, 2.5.x looks like it will open in a week or two, so we're not talking about long timeframes)."

8. Status Of GPIB Support

22 Jun 2001 - 25 Jun 2001 (5 posts) Archive Link: "GPIB support"

Summary By Zack Brown

People: Richard B. Johnson

Wan Hing Wah asked about GPIB support in Linux. He'd found a driver, but the latest version seemed to be from 1999, and he wondered if anything had been done more recently. Richard B. Johnson replied:

GPIB is terribly device-specific. What board do you intend to use? National Instruments has a so-called driver for their TNT4882 on their web-site. I was never able to get it to even compile, much less work.

I have a driver written for that chip. It's not GPLed, but it could be if there is enough interest. In any event, I could send you the source to try out. Just don't publish it yet. Let me know because I could use additional input for testing. In other words, if asked, I would just say that you are helping to test a driver...

9. Porting From 2.0/2.2 To 2.4

23 Jun 2001 - 26 Jun 2001 (7 posts) Archive Link: "Making a module 2.4 compatible"

Summary By Zack Brown

Topics: Backward Compatibility

People: Richard B. JohnsonTimur TabiJames LamannaJonathan Corbet

James Lamanna had a 2.0/2.2 module that had been developed by a company that was no longer in business, and he wanted to port it to 2.4; he had all the sources, but just wondered if any documentation existed on the various porting issues existing between earlier versions and 2.4.

Timur Tabi suspected there was no such document, but Richard B. Johnson attempted:

As a start:

wait_queue_head_t Now defined. You can do '#if !defined(...)` and make code changes backwards compatible.

Macro, THIS_MODULE is now the first member of struct file_operations.

Include <linux/init.h> __init data type for one-time initialization code or data. This is new, hense not backwards compatible.

Explicit initialization of spin-locks, SPIN_LOCK_UNLOCKED and/or spin_lock_init(spinlock_t *); If you fix this, it's backwards compatible.

ioremap() and friends is now required even for low memory stuff. You can no longer access this with a simple pointer, you must use readl()/writel(), etc., for proper defererence. If you fix this, it's backwards compatible.

These changes should get your module to compile (or nearly so).

Jonathan Corbet added that his new version of "Linux Device Drivers" would be out within a week or two (and available on the net shortly thereafter), and would either solve these porting problems or else fail in its mission.

10. FAT32 Good For Journaling?

24 Jun 2001 - 25 Jun 2001 (5 posts) Archive Link: "FAT32 superiority over ext2 :-)"

Summary By Zack Brown

Topics: FS: FAT32, Microsoft

People: Daniel PhillipsAlbert D. Cahalan

Albert D. Cahalan noticed that the FAT32 filesystem was unexpectedly compatible with the Phase Tree algorithm, which enabled it to offer full data integrity, better than typical journalling filesystems. Daniel Phillips replied, "Yes, FAT is what inspired me to go develop the algorithm. However, two words: 'lost clusters'. Now that may just be an implemenation detail ;-)" Albert replied:

What lost clusters?

Set bit 8 of "flags" (A_BF_BPBExtFlags to Microsoft) to disable FAT mirroring. Then the low 4 bits are a 0-based value that indicates which copy of the FAT should be used.

Assume we have 2 copies of the FAT, as is (was?) common. I'll call them X and Y. When we mount the filesystem, we disable FAT mirroring and mark FAT X active.

Now we can make changes to FAT Y without affecting filesystem integrity. Windows will not use FAT Y. As is usual with the phase-tree algorithm, we use free space to create a new structure beside the old one.

Time for a phase change:

We have FAT Y, currently inactive, updated on disk. FAT X is active; it describes the current on-disk state. We have a new root directory on disk, sitting in free space. We have a new filesystem info sector on disk, sitting in free space.

We write one single sector, then:

FAT X becomes inactive, and will not be used by Windows. FAT Y becomes active; it describes the new on-disk state. The old root directory is marked free in FAT Y. Good! The old filesystem info sector is marked free in FAT Y. Good!

Once the superblock goes to disk, FAT X may be written to.

Daniel asked for a patch.

11. Allocating Non-Contiguous Memory

27 Jun 2001 (4 posts) Archive Link: "Allocating non-contigious memory"

Summary By Zack Brown

Topics: PCI

People: Olivier GalibertAlan CoxRiley Williams

Olivier Galibert asked, "What is the Right Way[tm] as of 2.4.6 to allocate 16Mb as 4K pages and get the pci bus address for each page? Bonus points is they're virtually contiguous, but that's not necessary. IIRC, the old vmalloc-then-walk-the-pagetables trick is considered out-of-bounds nowadays." Alan Cox replied, "If you want it virtually contiguous then copy the code from bttv that out-of-bounds or otherwise is now found in about 8 drivers in the kernel. If you don't need that then you can map user space and use kiovecs - which is nicer for many things." Riley Williams asked if it would be good to redo the bttv code as a standard subroutine that could be called by each driver that needed it, but Alan smirked, "It would but then I suspect Linus wouldnt want to take it as it might encourage people to use it 8)"







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.