Kernel Traffic #4 For 4 Feb 1999

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1632 posts in 6415K.

There were 634 different contributors. 254 posted more than once. 243 posted last week too.

The top posters of the week were:

 

1. Philosophy Of The Stable Series
27 Jan 1999 - 28 Jan 1999 (14 posts) Archive Link: "I will _not_ start accepting patches!"
Topics: Development Philosophy, Mailing List Administration, Release Scheduling
People: Linus Torvalds, David Weinehall, Rik van Riel, Alan Cox

Linus Torvalds had some problems after releasing 2.2, because people thought it was time to start developing again (as opposed to just fixing bugs). He said, "2.2.0 may be out, but we're still in "serious bugfixes only" mode - and will be so for all of the 2.2.x series until I open up 2.3.x. I'm not interested in patches unless you can clearly show that the patches fix a _serious_ bug."

Alan Cox pointed out that the "ldd core" bug should be fixed. Linus agreed, but stuck to his general principle.

Meanwhile, David Weinehall, while agreeing with the basic schedule, wanted some kind of prediction for 2.3,and said, "The main issue is, however: when will v2.3.x be opened up? Maybe we should have some kind of wild wish-list/death-list brainstorm here before v2.3.x opens up?"

Rik van Riel interjected that "I don't think we should do that here. Linux-kernel already has far too much traffic. I'd be happy to set up a mailing list for that purpose, however." There followed a lot of support (and some dissent), and the list was created within hours of its proposal (send "subscribe linux-future" in the body of a message to majordomo@nl.linux.org if you want to join. The list itself is linux-future@nl.linux.org). A short time after that, Rik posted, saying, "It seems to work rather well since it's already got 34 subscribers in the first 5 hours of existance..."

So a new list is born.

 

2. User Mode Kernel
26 Jan 1999 - 28 Jan 1999 (8 posts) Archive Link: "Finally the 2.2.0 is out of sight :-)."
Topics: Debugging, Microkernels: Mach, User-Mode Linux
People: Marcin Dalecki, Oliver Xymoron, Michael Elizabeth Chastain, Malcolm Beattie

Marcin Dalecki felt some thought should be put into enhancing linux's self-debugging capabilities. He had this interesting suggestion: "What I'm thinking about is porting the kernel to run as a *compleatly* *normal* user level process. Something along those lines had been already imeplemnted by prof. Switzer at Univeristy of Goettingen. What he had done was in fact a pseudo micro kernel implemented as a UNIX programm running on a file containing his file system. It was called TUNIX (ftp://ftp.gwdg.de/pub/tunix) ."

The idea behind this suggestion was that such a port would allow linux to be dubugged as a user process, with all the bells and whistles of normal debugging tools. Also, unlike TUNIX, which was poorly done and buggy, Marcin asserted, "turning a *real* kernel in an compleatly arch independant way, by doing *just* another port into something like this, would be undoubtly of real value."

Oliver Xymoron was not immediately enthusiastic, and came out with, "I suggested something similar a while back but I realized it had conceptual problems. Presumably your user-mode kernel would want to run binaries for the same arch[itecture] it was built for, and have a way to reroute syscalls to the pseudo-kernel rather than the real kernel. That in itself is pretty ugly. Worse yet, I see no obvious way for this 'user-mode' kernel to do the necessary memory remapping it would need for its processes. Being run inside of the same real process, they would have the same view on memory."

Michael Elizabeth Chastain responded with, "In my view of the world, every process would be a direct child of the user-mode kernel (UMK). The UMK would handle the pseudo-parent- and-child relationships by proxy'ing syscalls such as wait and ptrace."

Oliver got a little more excited, and rounded out the idea a little with some thoughts on handling device drivers, "Have a file with a UMK to real device mapping, including mapping block devices to real drives or files and you're in good shape. If we want to go further and give real access to hardware, which might be useful when debugging a new driver, I/O is easy, user-DMA is being worked on, and interrupts could conceivably been down with downcalls (ew) or wacky signal semantics, though neither would fit the normal definitions of "fast". Fast here is probably not terribly important, since we're in a debugging environment."

Malcolm Beattie announced, "The timing of this is an interesting coincidence. I actually started thinking about porting Linux to a "uvmi386 architecture" ("User-mode Virtual Machine") a couple of weeks ago and started hacking last weekend." He added (after a lengthy description of the port), "Current status is that I've copied the i386 includes and arch tree to uvm versions, removed unneeded stuff from its config file (no DMA, no PCI, no ISA, ...) and hacked everything around such that everything builds but with some stubs and missing symbols for things I haven't done yet. It's not working yet and it'll depend on how many holes appear in my kernel knowledge as to how long it takes."

At this point Marcin, who started the thread, ended it with, "Perhaps I'm missing something here, but why not use MkLinux? It's Linux hosted atop the Mach microkernel. IIRC, you can run two Linux "servers" on top of Mach simulatenously, and use one of them to debug the other."

What took place during this thread? Did developers waste their time working on projects that already exist? Or did development of a new debugging tool just grow stronger? On the one hand, if MkLinux is really the way to go, several obviously qualified hackers learned where better to direct their energies. And if MkLinux is not quite what they are looking for, some disparate projects or potential projects have at least been united.

 

3. Echoes Of The ELF Migration
27 Jan 1999 - 28 Jan 1999 (5 posts) Archive Link: "Quite off topic, but I'm running out of options..."
Topics: Executable File Format

A short but sweet thread.

John LeMay had a problem where 2.2.0-final would repeat this message in an endless scroll at boot-up: "Kmod: failed to exec /sbin/modprobe -s -k binfmt-464c, errno=8 request_module[binfmt-464c]: fork failed, errorno=11"

Several people jumped in, and 17 hours after posting his question, John had the answer: he shouldn't have compiled ELF as a module.

If you don't know, ELF is (according to the Free Online Dictionary Of Computing) the binary format used by System V Release 4 UNIX. Linux also uses this format by default, although the old a.out format is still supported.

I remember when linux switched from a.out to ELF. Considering that we're talking about one of the most basic structures of the operating system, the change was virtually painless to all concerned. At the time, the issue was much debated. But even such an invasive operation seems to have left no scar. Well, maybe not no scar. Certainly some people still have problems with old sources that only compile as a.out, and then having to have a.out in their kernel.

 

4. Symlinks In The Kernel Sources
29 Jan 1999 - 30 Jan 1999 (6 posts) Archive Link: "2.2.x README missing info ?"
Topics: Source Distribution
People: David Balazic, Andreas Jaeger, Miquel van Smoorenburg, Justin Hahn, Linus Torvalds

Of interest to people upgrading.

David Balazic noticed that the new kernel's README (file:/usr/src/linux/README) file, "doesn't mention linking /usr/include/{linux|asm|scsi} to /usr/src/linux/include/..." as was required by previous kernels.

There was a staircase of replies to this, each building on the one before.

Andreas Jaeger said, "Yes, that's on purpose. For libc5, you have to link all three, but glibc has its own scsi subdirectory and therefore needs only linux and asm. To avoid confusion the Linus Torvalds decided to drop the reference completly."

Miquel van Smoorenburg added, "Especially since some distributions (Debian) don't need or want those symlinks at all. The libc6-dev package comes with known stable header files that are placed in /usr/include/{linux,asm} directly."

Justin Hahn vented with, "which is a royal pain in the sysadmin's ass when knfsd won't compile because it wants 2.1.x headers, and all you've got is 2.0.x in /usr/include" But Miquel van Smoorenburg countered with the suggestion of just adding /usr/src/linux-2.2.1/include to the compiler's include path; and pointed out that "if a module or any kernel dependant program thinks it can use <linux/foo.h> just like that and get the includes of the currently running kernel it's just plain br0ken."

 

5. Source Bloat; Linux In The Third World
29 Jan 1999 - 2 Feb 1999 (50 posts) Archive Link: "proper place to discuss kernel 'bloatedness'?"
Topics: Development Philosophy, FAQ, Linux In Government, Source Distribution
People: Chris Wedgwood, Michael Talbot-Wilson, Brian Gerst, Robbie Murray, Jonathan Lawson, Lars G. T. Joergensen, Robert Wuest, Richard Gooch

One of the biggest threads of the week. As Richard Gooch pointed out, it's covered in the FAQ (http://www.tux.org/lkml/)

Michael Loftis voiced his concerns that the kernel source was getting to be too big. He suggested that users should be able to select which modules to download, instead of having to get the entire source tree.

Chris Wedgwood replied, "I think this is unlikely, this gets brought up often. The kernel is one tar ball because it's easier to manage this way -- and people may as well get used to this," and Michael Talbot-Wilson added, "someone has to create a secondary level of source distribution, taking the single tarball and making available a number of smaller ones organized on an intelligible pattern. Then that secondary distribution has to make itself credible. The likelihood is that most people would ignore it. It would complicate matters, after all. So it's a nice idea, but probably a thankless task, and doesn't seem likely to go anywhere."

Brian Gerst pointed out, "Linus has been very insistent that he will not split up the kernel sources." He went on to suggest, "If you are really that low on disk space, and are not interested in things for other achitectures, you can prune the tree a little bit yourself. You can create a file that contains paths in the tree that you don't want tar to extract and use the -X option." But he added, "The biggest caveat to this approach is that patching the kernel will be a pain in the a**. Patch will complain about all the missing files. You may also have problems with make *config if you prune too much. These are the biggest reasons why Linus won't split the source."

Some folks started suggesting compiling on some other machine, and Robbie Murray had the strange suggestion that "it could even be made automatic. You send your .config to an email address, and it mails you the kernel," to which Jonathan Lawson added, "Actually I think this is an excellent idea ... It wouldn't be too long before commercial sale of big-time computing time is available (in a manner similar to the way ISP's work)."

In the same vein, though a different part of the thread, Lars G. T. Joergensen suggested, "make a website that looks like the Linux config. When done push the src into a tar-ball that can be downloaded. There are only a limited amount of combinations in the config.. so.. it's a finit task."

One of the most interesting arguments against kernel bloat came from Robert Wuest. Responding to the idea that megs are cheap, he replied:

I work with a bunch of guys who make very little money and are always scrounging parts to enhance their machines. $200 for a disk drive is two weeks salary.

This is in Mexico where the scholarnet project is trying to put Linux in 140,000 schools and other computing centers and I work in an area where wages are 'high'. The people trying to come up with this many computers in Mexico are going to be doing a lot of scrounging old hardware with little money to enhance machines. And those kids are going to take home a desire to run (and grow into hackers) on Linux in a home environment where wages are often less than $1/hr.

I personally could deal with the kernel if it grows to twice the current size, but keeping it as small as possible is very __important__ for Linux's expansion onto the desktop in developing nations and hence, important for developers to keep in mind.

These kinds of discussions may seem somewhat off-topic and a burden to the list (this one took up around 50 posts), but often the bazaar derives many good ideas from them. That's not to say that off topic threads are a good thing, but in this case some useful ideas did come up.

 

6. Big Memory Machines
30 Jan 1999 - 4 Feb 1999 (25 posts) Archive Link: "using more than 2 GB as a ram disk"
Topics: Big Memory Support
People: Manfred Spraul, Linus Torvalds, Cameron Simpson

Microkernels

Manfred Spraul asked the right question, apparently. Responding to Linus Torvalds' determination not to support more than 2 GB of ram, Manfred asked if Linus "would accept patches that make it possible to use the remaining memory as raw physical memory. The physical memory could be used for ram disks (->swap file), or for other devices that need lots of memory without kernel support."

Linus replied, "correct," and added, "The only people concerned about 2M+ on PC kind of machines tend to be database people, and they are more than happy to just get it as 'extra memory' rather than having it around as generic buffers for the page cache etc."

Cameron Simpson interjected, "ASIC people too, and they really do want it as generic buffers." He added, "Here (my workplace, not zip) we're readily getting into ASIC simulation work which wants buckets of memory. Intel boxes are cheap CPU and if/when our design tools get ported to Linux we would probably be very happy to have 2G+ of RAM." According to the Free Online Dictionary of Computing, ASIC stands for Application-Specific Integrated Circuit, basically a generic IC with a few custom masks on top.

 

7. Unicode For Mouse Selection And Keyboard Mapping
29 Jan 1999 - 3 Feb 1999 (46 posts) Archive Link: "Unicode console patch"
Topics: Developer Interaction, Internationalization
People: Marcin Kowalczyk, Stanislav V. Voronyi, H. Peter Anvin, Alex Belits

Edmund wrote a patch to extend unicode (http://www.digital.com/info/DTJB02/DTJB02SC.TXT) to mouse selection and keyboard mapping.

Stanislav V. Voronyi had written a similar patch, but said that Edmund's was better, and tried to merge the most useful parts of his own with Edmund's.

Meanwhile some bug fixing of Edmund's patch took place on the list, though integration with the kernel will almost certainly have to wait until 2.3. However, Marcin 'Qrczak' Kowalczyk pointed out that "linux standard line discipline erases only a single byte with Backspace, even in UTF-8 mode, although on the screen the cursor goes back the whole character. This needs fixing," to which Stanislav replied, "Yes, it is a real bug. And imho this must be fixed in 2.2"

H. Peter Anvin had some complaints about Stanislav's patch, and said, "I'm working on a completely new console spec that is ISO 2022-compliant (the current console isn't, and cannot be made to be.)" to which Stanislav replied, "If you need volunteers for this I am first."

There was some dissent, however. Marcin put in, "I vote against complicating the whole thing by adding full ISO-2022 support. UTF-8 is almost done, is *much* simpler and AFAIK gives nothing less than ISO-2022."

Another kind of objection was seen in Alex Belits' passionate plea:

the multiple languages/charsets support, both in serialized form (charsets switching, labeling of chunks of text) and internal representation (language/charset-labeled strings) should be implemented in such way that multiple languages support will be possible in some natural way. It should be possible to place at least some generic language-dependent code (input, sorting, phonetic matching, hyphenation/formatting...) into libraries, and load versions for different languages/charsets when text in such languages/charsets is processed. This can become a real, useful languages support framework, and it's a shame that there is still no such thing now, and people can only face a choice between bad internationalization support and even worse one.

Indeed, we need a better standard, but that standard should not originate from the needs of kernel driver for text console -- it should be targeted to real application development, and once that thing will be done, it will be possible to modify console drivers, xterm, etc. to fit it. Right now it probably will be better to leave poor console alone, and do something to make some reasonable language/charsets labeling/processing design. Once that is done, implement it in things where the addition of it will be the least painful -- X libraries, editors, etc. If it will succeed, make console driver that will be compatible with it -- and I believe, such console will be much more simple and clean than whatever can be done now, when standards are messy, and ideas in their base are either no longer valid, or unclear.

Despite loudly proclaimed victory of Unicode over everything that speaks and writes, it's not yet too late to make a better alternative. If it will be done, we will have a chance to have a framework that allows clean handling of multiple languages and charsets in a manner that will allow to respect those languages and their rules without resorting to messy bloat of application-specific language handling everywhere.

 

8. Proxy ARP Out Of The Kernel
29 Jan 1999 - 3 Feb 1999 (22 posts) Archive Link: "Proxyarp is not working with kernel 2.2.0"
Topics: Kernel-Space Versus User-Space
People: Victor Khimenko, Alan Cox

Denis Chapligin complained that proxy ARP was apparently broken in 2.2.0 kernels. According to the Free Online Dictionary of Computing, "Proxy ARP allows a site to use a single IP address with two physical networks."

Victor Khimenko replied that proxy ARP was an ugly hack which was removed in 2.1.x kernels, "more then half-year for sure; may be year," and Alan Cox added, "It wasn't simply removed. Proxyarping subnets is very unusual , slows the general code down and can be done in user space. That makes the entire kernel case look dubious."

 

9. Maximum Size Of ext2 Partitions
29 Jan 1999 - 1 Feb 1999 (7 posts) Archive Link: "What is max size of ext2fs?"
Topics: FS: ext2
People: Stephen C. Tweedie

Hoang Manh Hung posted an empty message with this subject, which sparked a bit of discussion.

Ralf did some multiplication of some limits and came up with a theoretical maximum of 4 Terabytes, but Stephen C. Tweedie pointed out that the devices themselves (independant of fs) could only currently support 2 TB under linux, and possibly less under certain conditions.

 

10. SMP Showstoppers
1 Feb 1999 - 3 Feb 1999 (33 posts) Archive Link: "[patch] SMP fixes 2.2.1"
Topics: Development Strategy, SMP
People: Ingo Molnar, Alan Cox

Ingo Molnar started this one up with a big SMP patch. As he put it, "They affect only a small percentage of SMP boards, but for them these are real showstoppers." On the same day, he posted an updated patch based on debugging by Manuel J. Galan and Mark-Andre Hopf, and two days later posted another one based on debugging by a lot of people.

Meanwhile, his initial patch sparked a big discussion about a separate SMP problem, which Alan Cox blamed on the BIOS. Mark-Andre Hopf seconded that opinion, and Ingo posted a new patch, saying, "we have a problem i did not want to solve until 2.3 but we might have to."

 

11. Mailing List Problems
1 Feb 1999 - 2 Feb 1999 (3 posts) Archive Link: "No response"
Topics: Mailing List Administration

More problems with people being unceremoniously dropped from the list. Apparently if a message bounces, the server assumes you no longer exist. Seems like there must be a better solution, but with the server so overloaded, it's difficult to see what that might be.

 

 

 

 

 

 

We Hope You Enjoy Kernel Traffic
 

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 kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License, version 2.0.