Kernel Traffic #13 For 8 Apr 1999

This week we've got a slightly new look. The Kernel Traffic main page is now pretty much unchanging, and each issue is given a unique link right from the start, instead of starting off on the main page and then moving to a permanent home later. This new setup will make it easier for web indexing bots and whatnot.

I'd like to say a few words to try to explain some of the complex issues surrounding the "Linux" vs. "GNU/Linux" controversy. Richard M. Stallman says we should all use the term "GNU/Linux", ostensibly because Linux systems are really what the GNU project had envisioned, but with the Linux kernel added in. Part of why this issue has gotten so out of hand is that this is not his real reasoning. But I'll come to that.

Before I go on, I should say something about Stallman himself. His contributions to free software are immeasurable. He created the tools that allowed the creation of things like Linux; he created organizations to foster such things; and he created the GPL. He's been fighting for decades for the cause of free software, a cause that we are all now able to enjoy. We mustn't undervalue him and his work. We would not have Linux if not for his tireless efforts. He deserves whatever benefit of the doubt we can give him.

Above, I said he was using a false justification to support his claim. His true reasoning (which he does occassionally state) is that GNU should get recognition, and so Linux should use its position of fame to give GNU that recognition. The "Linux is really GNU with a kernel" argument is just a handy justification of adding "GNU" to the name. But as people have pointed out many times, GNU software forms only one significant portion of the whole OS; therefore, to call the system "GNU/Linux" is not a more accurate name than "X/Linux" or "BSD/Linux" and so on.

This dichotomy between (a) Stallman's choice of broken logic for the name-change itself, and (b) the true reason for wanting the name-change; means that people continue to point out the broken reasoning, and Stallman continues to ignore those objections. The results are massive flame wars, tremendous frustration toward Stallman, and in some cases a total rejection of GNU and its ideals.

Another thing that tends to aggravate people is that Stallman not only insists on this name-change, but he insists so strenuously. At every interview, every speech, every press conference, he drives home his position, insisting that interviewers and reporters adopt his terminology before he will proceed.

Many people see this behavior as directly hypocritical to his stated cause of freedom. His insistence on this name-change seems to go against the very philosophy he claims he has been fighting for. And the almost feverish intensity of his insistence seems only to highlight that hypocrisy.

Some argue that he is only turning himself into a pariah, and bringing harm to his cause. They say the press will tire of him and begin to treat him as a kind of humorous fool; and they argue that if Stallman would simply wait patiently, eventually the same recognition currently washing over Linux would seek him and GNU out as well. After all, Linux is licensed under the GPL, and it is impossible to grasp the history of Linux without grasping the significance of GNU and the Free Software Foundation. Anyone at all interested in Linux must sooner or later discover GNU.

I believe that Stallman's motivation here springs from the fact that he is an activist. It is not (nor could it be) in his nature to sit and wait. If it were, Stallman would never have started the GNU project, founded the Free Software Foundation or developed the GNU General Public License. He must persist even in the face of the public outcry against him. He would rather go down in flames than wait patiently for some possible success.

It is important to understand these things, because without that understanding, Stallman's actions seem those of a raving, jealous, bitter person who cannot see the better alternatives that are right in front of his face. I believe many people have this image of him now, and even more will in the future. But it is not a correct image. He has an idealistic goal, and is doing whatever he can to further that goal, including stirring people up, inciting them to talk about the issues, inciting them to write editorials, and in one way or another keeping the issues alive. We may curse him for it, but his strategy is in some ways successful. People are aware of the GNU project, much more so than if he had kept quiet. We may say that the backlash outweighs the benefits, but that's a matter of opinion.

While many Linux users (myself included) think that the name "GNU/Linux" is a bad idea, I don't think anyone can find fault with the underlying assumptions: the GNU project is good. The ideals of free software are good. And just because things are going so well with Linux now, that doesn't mean there are not powerful enemies of free software, doing all they can against it.

So my suggestion is for people to be tolerant of Stallman, and to be aware of the deeper ideas involved. Look beyond the objections you may have to this or that little point or this or that annoying aspect of his personality, and think about the larger issues, the freedoms that are at stake, and how we can all act as a true community, to ensure those freedoms, and educate others as well. We don't have to be as belligerent and frustrating as Stallman, we can try to do good in our own way, just as he tries in his.

There were 408 different contributors. 150 posted more than once. 144 posted last week too.

David Howells posted an oops, saying, "I discovered crond/updatedb had four outstanding find programs all hanging in the "D" state whilst searching my NT partition. I then discovered the an oops in the dmesg log and ran it through ksymoops." There was a small bit of discussion, then several days after the thread seemed dead Joseph Malicki said, "This oops was discussed a while ago. NTFS runs out of memory, and doesnt check the kmalloc. It was fixed by Steve Dodd and is in 2.2.3ac?, and i THINK 2.2.4. The new version of NTFS (990323) also fixes this." David replied, "The problem appears to be fixed by linux-2.2.4-ac1"

Horst von Brand noticed that, when compiling under SPARC, "fs/proc/mem.c uses pte_read(), which seems to be #defined in each include/asm-<target>/pgtable.h, but not for SPARC." Bert de Bruijn replied, "this is still not fixed in 2.2.5ac1" and added, "the kernels in the ultrapenguin distro seem to avoid this by using a different fs/proc/mem.c, where pte_read is not called." David S. Miller put in, "or just use the normal 2.2.5 where the same is true and things work fine on both sparc ports," and Alan Cox added, "You can either use the old proc/fs/mem from 2.2.5 if you want to use the -ac tree with a sparc, or just use 2.2.5. Unless you need the NFS client stuff and/or the big file arrays I'd recommend just using 2.2.5." He finished up with, "Or of course, you can fix it 8)"

Loren Osborn has been extending gpm to support mouse wheels. He posted to linux-kernel looking for a way to programmatically initiate the standard shift-pgup/shift-pgdn scrolling actions. Dominik Kubla replied, "There is no support for this (at the moment). ISO 6429 (aka ECMA-48) defines terminal control sequences to scroll in "page memory" upwards, downwards, left and right. I have started to implement missing pieces from ISO 6429 (CBT, CHT, CVT, ...) but so far i haven't touched any substantial code (like implementing page memory would mean), especially since i want to avoid any clashes with the plans to make the console code ISO 2022 compliant."

Eric Fagerburg came in with, "this is the third instance I've heard where someone wanted to do a <Shift-PgUp> and/or <Shift-PgDn> under program control. A fellow I talked with in the Netherlands suggested either a new ioctl to allow us to insert scan or key codes (TIOCSTI already lets us insert most anything else) or else define a new device (like /dev/rawkey) that does the same thing. I've been crawling around in devices/char/keyboard.c in my spare time to assess the feasibility of these ideas." Regarding mouse wheels, he added, "there seem to be enough needs for this that I think it's worth playing with. I'd be glad to help out with the implementation. If someone has a good feel for whether the ioctl or new device route is the best I'd be glad to hear about it."

Christophe Leroy asked where he could find some docs on how to write a frame buffer driver. Ben Pfaff pointed him to /usr/src/linux/Documentation/fb and said he didn't think much else was out there. He also suggested reading the source of other frame buffer drivers. James Craig agreed, and suggested the TGA driver as being particularly simple to grasp. Meanwhile, Jes Sorensen gave a pointer to Geert Uytterhoeven's page <http://www.cs.kuleuven.ac.be/~geert/Console/>.

Brian Moyle posted a small patch to the list to fix the obsolete function arp_set_predefined() to work with external loopback with crossed routing. The test setup he used to verify the patch was to connect two NICs together using an external cross-over cable; he swapped route entries (to force packets out the opposite interfaces), and then issued pings, telnets, and ftps to both addreseses. He unplugged the cable to verify that the pings, etc. were appropriately halted.

Alan Cox was unamused. He said, "The kernel knows perfectly well that its silly to send packets to yourself via external interfaces. This patch isn't needed. The bug is your routing table and trying to set up this configuration."

Pavel Machek objected that he could also benefit from the patch, and Pete Popov was also nonplussed. To Alan he replied, "why is it silly? Because it's not useful to you or any other kernel hacker? Neither you nor any other kernel hacker can envision all the possible ways linux might be used. We find the patch _extremely_ useful in our production and test line. It allows us to fully test and manufacture mutiple I2O LAN adapters in a single system and it would be a lot more convinient if the patch was part of each linux instalation, rather than having to compile a new kernel each time." He also insisted that the bug really was with the kernel.

There are two reasons Im not putting this in

Its a very specialised need. The patch is fine if you need it add it - its more specialised than other "not needed" patches people keep out of the main tree.
Its on a common code path. Sum the number of times that path is taken by the number of users of Linux versus the 3 or 4 who actually need it.

There isnt anything wrong with the patch, its just not relevant to the userbase as a whole and its on a regularly executed path

Richard B. Johnson had some soothing words to offer the pro-patch contingent. He said, "I think you could also send it to Alexy and if he likes it, Alan will probably be persuaded to put it into the mainstream. I think it is a very good idea. If it is implemented in such a way that it has essentially zero impact upon normally-configured networking, I think you have a winner. However, you are going to have to convince several important people. These people are reasonable, but not easy. Don't give up yet."

One other interesting feature of this thread is that it clears up any lingering doubts about who is in charge of the 2.0 series. Maybe if Linus Torvalds wanted to throw his weight around he could take over 2.0 development -- and maybe he couldn't; but for all intents and purposes 2.0 is a kernel fork belonging to Alan.

Pavel Machek was quite happy with CODA. He found it functional and well designed, a good replacement for userfs. He just had a couple complaints, one of which was that the module seemed to hang around even after being unloaded. He posted a patch, missed by David S. Miller, who replied that the behavior was a side effect of dentry caching in VFS, and suggested, "Run some program which will just use most of your RAM, watch afterwards how 'lsmod' output report that all remaining references to the coda module have gone away, you may unload the module now." Pavel gently reminded David of the patch. David acknowledged, slightly embarrassed; and asserted that the behavior he'd described did also occur, particularly with modules which create procfs directories or files.

Lokesh Setia was writing a server which would theoretically have thousands of clients connecting at once; as far as he knew Linux had a 50-60 socket cap on each process, and he wanted to know how to get around that. Alan Cox clarified that the maximum was 256 sockets in 2.0.x and 1024 in 2.2.x; he also pointed out that a patch existed to take 2.0.x to 3000, and the 2.2.x-ac series could go much higher.

Gerold Jury pointed out that he wasn't getting those numbers in his experiments. Stress-testing by opening as many sockets as possible, he could still only get approximately 1000, even with the -ac patches. A couple people pointed out that 'ulimit' could solve the problem. This made Gerold very happy, and the thread was over.

Am porting the Linux kernel to a new architecture (the 370 instruction set). I noticed that the timer interrupt does very little. The question is this: how does scheduling work if/when there are no other interrupts occuring? e.g. have two numeric processes running, neither is making system calls, neither is swapping. etc.

The esa/390's are mainframes; there are no serial ports, no video or video interrupts, no regular i/o or bus interrupts; nothing else is ticking in any sort of quasi-periodic manner. What should I do, make the timer interrupt do a schedule every ten ticks or something?

Amid the general excitement and helpful tips, Alan Cox asked, "I thought IBM had/were doing that?" Linas replied, "!?! I keep hearing unsubstantiated rumours about this. Since I also just happen to contract at IBM, I am not sure if those rumours are about me or someone else. If anyone can provide something more specific, please let me know," and added, "BTW, My project is *not* officially sponsored or sanctioned. Its a stunt. Feel free to offer me a job to allow me to continue this work :-)."

Siddharth Srivastava was looking for a good asm debugger for Linux. Andreas Schwab suggested gdb, but Chris Wedgwood had this criticism:

It requires a sane stack frame -- something which wastes a register when tuning asm up the wazoo.

Aside from that, it's a horrible debugger for assembly. Something like Borland Turbo Debugger would be nice at times... (not the gui necessarily, but that level of functionality).

There are two things available:

1. IKD (very nice combination of various kernel hacking things including tracing, memory leak detection, xkdebug etc). Drawbacks: breakpoints and single-stepping not 100% reliable. Maintained by Andrea Arcangeli.

Available on ftp://e-mind.com/pub/linux/patch-ikd-arca/ (last time I checked it was for 2.2.4, no 2.2.5 yet).

2. remote debugging over serial cable (maintained by dave@gcom.com as a separate package gdbstubs on ftp.gcom.com but I made it available as a patch on http://www.aivazian.demon.co.uk/patches). Latest version is suitable for 2.2.4. If people ask (and even if not) I will make 2.2.5-suitable version patch soon (tonight maybe).

Andrew Morton suggested his 'mix' tool, which outputs a handy mix of C and assembly; and Peter Steiner suggested the integrated development tool RHIDE.

I made Linux-2.2.5 yesterday (as some people already have noticed: due to popular demand I try to delay the announcement for some time in order to let the thing percolate to mirror sites, in case anybody wondered).

The 2.2.5 release is meant to be a final cleanup release before I leave for a two-week vacation. So please take these release notes to also mean that it is probably a good idea to hold off emailing me stuff directly, unless it is a major bug that you really think I should look at immediately. I would suggest people discuss problems on the mailing list and on the newsgroups, where other competent people are, rather than expecting me to do much about it.

Also, note that there have been various indications that egcs potentially miscompiles the kernel, or at least makes some problems worse. We don't know whether that is due to one or more kernel bugs, compiler problems, or just combinations of "features" in both. I would suggest that if you have problems you at least verify whether the problems still exist with gcc-2.7.2.

That said, I bet that both the kernel people and the egcs people would be really happy the more people look into this - if somebody feels motivated enough and sees problems with egcs, it would be extremely powerful to try to pinpoint the particular file that seems to bring on the problems. I'm afraid it needs a known failure mode and lots of legwork to find out what triggers it, though.

Anyway, 2.2.5 does:

compiles with accounting.
add support for Microgate SyncLink and Synchronous HDLC
stallion driver update
alpha EV6 and SMP fix for bootup with newer compilers
ptrace fix for sparc/i386
small sparc updates
floppy driver could oops at bootup under certain setups
random driver updates (bw-qcam, sound driver error codes, etc oneliners)
FIOASYNC ioctl fix
network locking fixes
SMP "struct user" and signal sending fixes

Have fun, because I will.

There were a few comments about the egcs issue. Brandon Black, for one, had no problems at all, though he was running all the latest bleeding edge stuff, from kernel to compiler to libraries to binutils. Daniel Egger was not so lucky, and had trouble compiling the isdn drivers with egcs. Matthew Kirkwood reported that Jeff Law seemed to have a bead on something in the egcs mailing list, but David S. Miller said he thought that was a separate problem.

So the egcs issues have become more and more difficult to see, which may be similar to saying they are gradually fading away. At least no one's getting cinders in their eyes: the sputtering flames from a while ago seem to have died down completely.

Thanks go to Eli Marmor for pointing this thread out to me. It took place on linux-usb. Apparently Linus Torvalds started his own USB code in the hopes that it would be easier to work from than the existing stuff written by Inaky Perez Gonzalez. Linus said:

I've been using some of my copious spare time (hah!) to explore USB the last few weeks, and I have a driver that is set up fairly differently from the standard Linux-USB driver, but that shows some promise. It only works with UHCI controllers right now, although that is simply because I didn't want to bother with a USB controller that I don't have access to anyway.

If somebody wants to look at a simple debug-only USB mouse driver, feel free to look at ftp.kernel.org/pub/linux/kernel/testing. It's designed to be more direct-to-the-hardware than uusbd, because I found the uusbd code hard to follow. So it's kind of simplistic, but simple is good.

And it's called 0.01 for a very good reason: don't expect very much from it. I'm mainly sending out this email to just get some comments.

A number of people felt Linus' patch should be given a close look. Apparently he wasn't the only one having trouble following Inaky's code. Several folks confessed they'd been trying for quite awhile to understand the code and making no headway at all. They felt if Linus' code would make it easier to contribute, it should be adopted.

Other folks were not in favor of that. Their feeling was that USB was very complicated by nature, and any code that got written would have to either accommodate that or abandon a lot of USB's abilities. Some luminaries like Lennart Augustsson, who wrote the USB stack for FreeBSD, came out on this side of the issue.

Inaky, for his part, was quite active in the thread, not coming down hard on either side, but discussing the possibility of documenting his code better, so new folks could follow it. My guess is that Linus' code will not be adopted. I think the general consensus of the list followed the lines of, "USB is just going to be hard to implement, and shouldn't be artificially simplified."

One interesting part of the thread had a touch of bitterness, and perhaps also a touch of deeper truth. At one point after there had been a bit of back and forth and everyone was considering the total departure suggested by Linus, Mike Smith said to Inaky, "BTW, good luck with the disharmony that Linus has introduced. It must suck having these unassailable godheads wandering around."

It's a strange and real problem: how can Linus involve himself with a new project anymore, without completely shaking it up and possibly causing a complete reorganization of the project?


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	22 Mar 1999 - 29 Mar 1999	(8 posts)	NTFS Out Of Memory In 2.2.3
2.	23 Mar 1999 - 30 Mar 1999	(4 posts)	SPARC Compilation Problem In 2.2.4 And ac Patches
3.	25 Mar 1999 - 29 Mar 1999	(4 posts)	Console Scrolling With Mouse Wheels
4.	27 Mar 1999 - 29 Mar 1999	(5 posts)	Searching For Framebuffer Docs
5.	27 Mar 1999 - 31 Mar 1999	(13 posts)	Alan Cox In Charge Of 2.0 Development
6.	29 Mar 1999 - 30 Mar 1999	(5 posts)	CODA Discussion
7.	28 Mar 1999 - 1 Apr 1999	(13 posts)	Opening Thousands Of File Descriptors At Once
8.	28 Mar 1999 - 31 Mar 1999	(8 posts)	Porting To The IBM 370
9.	29 Mar 1999 - 30 Mar 1999	(10 posts)	Linux Debugger For Assembly
10.	29 Mar 1999 - 31 Mar 1999	(9 posts)	2.2.5 Announcement; Linus Goes On Vacation
11.	5 Apr 1999 - 16 Apr 1999	(30 posts)	Linus Descends On USB

Kernel Traffic #13 For 8 Apr 1999

By Zack Brown