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.
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).
Cort Dougan said:
Starting today, Paul Mackerras (paulus@samba.org) 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 vger.kernel.org CVS tree. Changes should continue to flow into the main tree available from kernel.org.
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 http://www.linuxppc.org.
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.
- It makes integration with user-space tools (ip, ifconfig, arp...) a non-issue.
- It is logically correct, a VLAN is a (net_)device and in all ways acts like one.
- 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.
- 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: http://scry.wanfear.com/~greear/vlan.html 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.
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.
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.
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:
http://www.microsoft.com/business/licensing/sharedsource.asp
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 http://www.microsoft.com/BUSINESS/licensing/sscommitment.asp, 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.
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).
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...
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.
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.
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)