Kernel Traffic #204 For 7 Feb 2003

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1130 posts in 5245K.

There were 364 different contributors. 186 posted more than once. 150 posted last week too.

The top posters of the week were:

1. Replacing pcihpfs With sysfs

21 Jan 2003 - 29 Jan 2003 (9 posts) Archive Link: "[PATCH] Replace pcihpfs with sysfs."

Topics: FS: sysfs, Hot-Plugging, PCI

People: Greg KH

Stanley Wang posted a patch to replace pcihpfs with sysfs, and asked Greg KH what he thought of it. Greg was happy to get the code, and thought it was very close to being acceptable, but unfortunately, he said, sysfs was not able to support some of the hotplugging requirements to fully replace pcihpfs at that time. This didn't invalidate the patch, it just meant they should leave some place-holders in the code, for when sysfs supported the needed functionality. At one point, Stanley thought he'd found a way to eek what they needed from sysfs, and posted a patch, but Greg said, "No, this patch does not update the proper file within sysfs, only the directory entry, which isn't what we really want. I just sent off the following patch to Pat Mochel that adds sysfs_update_file() to sysfs, and modified the pci hotplug core to use it." Stanley agreed this was more elegant than trying to work around sysfs' deficiencies, and the thread ended.

2. IDE Heading Toward Hotplugging Support

25 Jan 2003 - 31 Jan 2003 (9 posts) Archive Link: "[PATCH] Update PnP IDE (2/6)"

Topics: Disks: IDE, Hot-Plugging, Power Management: ACPI

People: Adam BelayAndre HedrickAlan Cox

Adam Belay posted a patch and explained, "This patch converts the ide driver to the latest pnp changes. I do not have this hardware so this patch was only tested for compilation. Please note: I added ide_unregister to ide.h becuase I needed it for the driver conversion. Please let me know if this is not the proper unregister api for ide devices." Andre Hedrick said, ""ide_unregister" is only called if you are physically removing the controller. If PNP is going to permit physical removal when the OS is HOT, it may be justified. This can make a "hole" in the rest of the driver an generate an OOPS. IDE-CS has alway insured the ordering was last." He said he had to think about it a bit more; but Adam continued, "At least in theory, any pnp device could be hotplugged. Of course it depends on which protocol the ide drive is represented by. ISAPnP is completely static where as PnPBIOS, and potentially ACPI in the future, support docking stations and other removable pnp devices. Support for PnP hotplugging is very limited at the moment however it is best to design drivers around this feature so we don't have a mess when PnP hotplugging is finally used. Also if a pnp protocol was presented in a removable module format, the protocol may want drivers to detach from its devices upon module unload. Are there any other hotpluggable ide devices and if so how are they handled?"

At this point Alan Cox remarked, "The IDE layer does not currently handle hotplugging. It needs a lot of work before that can happen." Adam asked, "Would you suggest I remove the ide_unregister and place a error message if that area is ever called in the pnp ide driver or is it better to leave it in there? I'd like to get this patch out soon so users can take advantage of these changes. Becuase pnp does not currently support hotplugging, I doubt there will be any problems." Alan replied, "Leave it there then, the IDE layer will eventually develop hotplug - its taking baby steps that way."

3. Status Of VISWS Support

26 Jan 2003 - 30 Jan 2003 (3 posts) Archive Link: "[PATCH] visws support for 2.5.59"

Topics: VisWS

People: Andrey PaninChristoph Hellwig

Andrey Panin posted a patch to get SGI Visual Workstations (VISWS) working under 2.5.59, and asked folks to test it out. Christoph Hellwig was happy to see the patch, and offered some comments. He also said he hoped Linus would take the code into the main tree soon. In private email, Andrey said, "The visws support is totally borken now, so why submit this ASAP ?" And Christoph replied on linux-kernel, "the visw fb driver can't work anyway, so there's no harm if you get this driver update into James' tree (an he'll submit it to Linus with the other fb stuff) soon, but your patch will get a lot smaller and easier to integrate."

4. An Attempt To Gain Permission To LGPL Parts Of The Kernel

28 Jan 2003 - 31 Jan 2003 (7 posts) Archive Link: "Permission to use atomic code under LGPL"

People: Christian Fredrik Kalager SchallerPavel MachekRussell KingChristoph Hellwig

Christian Fredrik Kalager Schaller from the GStreamer project (http://www.gstreamer.net) said:

We did a small license audit the other day and discovered we included some code from the kernel. GStreamer uses the LGPL so this is a problem for us.

The code in question is the atomic code and is included in our sourcefile below. Do the person(s) in question responsible for this code mind if we re-license it under the LGPL?

We will of course add comments in the code stating its origin with copyrights etc.

Only Pavel Machek replied, to say that "atomic stuff is widely considered "too trivial for copyrights to apply", so LGPL should be OK." Three days after his initial post, Christian said, "I got no objections to my request to use these few lines under the LGPL so I will now update our sourcefile to make sure linus gets copyright and origin is informed of." This time he got more of a response. Russell King pointed out:

In any case, "no objections" and certainly "no response" is not the same as "being granted permission". You can not take silence as a positive outcome to these questions, unless you're on a deathwish to get sued.

You need *explicit* permission of the author in order to use any code in a way not covered by the license under which that code is distributed.

Christoph Hellwig also came down on Christian, saying, "Umm, you didn't even ask Linus himself nor did you actually research who wrote that. And waiting three days while Linus is known to be away until you claim he implicitly agreed on you taking his code.." Christian said he hadn't known Linus was away.

5. Secure Distribution Of New Kernel Sources

28 Jan 2003 - 30 Jan 2003 (20 posts) Archive Link: "kernel.org frontpage"

People: H. Peter AnvinKasper DupontChris FriesenValdis KletnieksRussell KingJohn Bradford

H. Peter Anvin announced, "Just in case anyone cares :) I have changed the kernel.org frontpage from linking to .gz to linking to .bz2 files. It should now also display snapshot releases if they exist." John Bradford suggested also linking to the respective public key signatures that verify that each file is what it claims to be. But H. Peter replied that those signatures were only useful for identifying cracked mirrors. Kasper Dupont pointed out, "I believe I can also use them to check against a MiM attack against my connection to kernel.org." H. Peter and John agreed with this, and H. Peter added, "You can, assuming you have a trust path to the key."

Elsewhere, Valdis Kletnieks suggested that the signatures could also identify if the primary site had been cracked, but H. Peter said this was not true. The primary site could not be verified using those signatures. Chris Friesen suggested, "Perhaps for the truly paranoid the signatures should be posted to this newsgroup and digitally signed by someone trusted." Valdis replied:

It's called the PGP web of trust. There's already some 107 signatures on the PGP key - who else would you want signing it? The point is that we've already (presumably) proved via the web-of-trust that PGP key 517d0f0e is in fact the proper key, and that for an intruder to post a valid signature of a trojaned .tar.gz would require them to *ALSO* compromise the machine that the signing is done on (hopefully a different machine than ftp.kernel.org).

Yes, an intruder could leave a forged signature with a random key easily. But to leave a forged signature with the key that's already on my keyring is a lot harder...

Russell King came in with:

I believe a script signs the files on ftp.kernel.org, which means the private key is on the master machine, probably without a pass phrase. That means that if the master server is compromised, its highly likely that a rogue file will have a correct signature.

As hpa says, the GPG signature provides no assurance that Linus put up patch-2.5.60.bz2 and not some random other person.

The only way to be completely sure is for Linus to gpg-sign the patches himself at source with a known gpg key using a secure pass phrase before they leave his machine (preferably before the machine is connected to the 'net to upload them for the really paranoid.)

6. Updating The Boot Sector Code

29 Jan 2003 - 4 Feb 2003 (2 posts) Archive Link: "[UPDATED PATCH] Removal of boot sector code"

People: H. Peter AnvinMikael Pettersson

H. Peter Anvin said:

I have updated the boot sector removal code so that it now:

a) Supports "make zdisk", "make bzdisk" and "make fdimage" (Requires mtools and syslinux, but will work as a non-root user as long as you have your floppy in /etc/fstab or syslinux setuid root.)

There is also "make fdimage288" to create a 2.88 MB floppy image.

b) Is slightly more paranoid about the message-writing code than it was before.

The boot sector was very cool in 1992, but in 2003 it has outlived its usefulness, and it no longer supports what Linux boot loaders need, especially not with the 1 MB limit and the lack of support for non-legacy floppy devices (the geometry detection hack fails on those.) Even a relatively simple 2.5 build exceeds that size for me, and with this patch "make bzdisk" actually works, whereas the original boot sector doesn't.

Mikael Pettersson liked the 'make fdimage288' option, but said, "it does require MS-DOS fs support in the kernel, and having a /dev/fd0 entry in /etc/fstab with "user" permissions (for some reason, "owner" doesn't work). I'd like to use my own recipe for "make bzdisk", to avoid these restrictions. What about having "make bzdisk" optionally invoke and external script, similarly to how "make install" works?" But there was no reply.

7. New Smatch Bug Hunter And Database

30 Jan 2003 (1 post) Archive Link: "[Announce] Smatch checker / bug database"

Topics: Bug Tracking

People: Dan Carpenter

Dan Carpenter announced:

I have been working on an error checker called Smatch that was inspired by the Stanford Checker. The project page is at http://smatch.sf.net

Smatch is useable but still in pre-Alpha stage. Email me or smatch-dicuss@lists.sf.net (mailto:smatch-dicuss@lists.sf.net) if you have any problems. So far, I've been really good at replying promptly.

On the smatch.sf.net page there is a link to the database of bugs Smatch scripts have found. A lot of the bugs turn out to be false positives so the web page has a feature where you can create a login and mark a bug as a false positive.

8. Status Of SquashFS

31 Jan 2003 - 3 Feb 2003 (2 posts) Archive Link: "any compressed filesystem suggestion ?"

Topics: Disk Arrays: RAID, FS: SquashFS

People: Phillip Lougher

Nicolas Turro asked for recommendations on a good compressed filesystem for backups. It had to run on hardware-based RAID, and allow administrators to add files to the archive. He remarked that squashFS was disqualified because it was read-only, but Phillip Lougher replied:

Append capability is the thing I'm currently adding to Squashfs. Once finished, you'll be able to add new files/directories to the top level directory of a previously created filesystem. As the mksquashfs program performs duplicate file checking against the files in the filesystem as well as the files being added, this means it will also work as a kind of incremental archiving filesystem.

An initial release should be ready in a week (or two depending on free time).

9. Status Of Startfire Network Driver In 2.4

31 Jan 2003 (1 post) Archive Link: "[netdrvr starfire] VLAN support, 64-bit support, bugfixes"

People: Ion Badulescu

Ion Badulescu announced:

This patch (against 2.4.21-pre4) updates the startfire network driver to my latest non-NAPI version. It adds accelerated VLAN support, 64-bit DMA support, and fixes a number of bugs, one of which (the disable DMA on shutdown) has real potential to corrupt random memory.

I've got a couple of positive reviews from beta testers, including one confirming that this update closes a race that was fatal under stress with the old driver. Unfortunately these Adaptec cards are pricey so not many people buy them...

10. Perl In The Configuration System

31 Jan 2003 - 1 Feb 2003 (22 posts) Archive Link: "Perl in the toolchain"

Topics: Klibc

People: Pete ZaitcevKai GermaschewskiJeff GarzikJ.A. MagallonH. Peter Anvin

Pete Zaitcev asked about a post from the previous day (http://www.uwsg.indiana.edu/hypermail/linux/kernel/0301.3/1203.html) in which Konrad Eisele proposed a patch that included inline Perl in a Makefile. In that earlier exchange, Pete had said, "Personally, I am opposed to a use of perl, because it's not installed in my sparc userland, so I would not be able to self-compile a leon or joint kernel. But ultimately this is not my call to decide. At one point, Linus approved Python into the toolchain. So, present good evidence of need and post to lists." Now he asked Kai Germaschewski for his opinion on the matter. Kai replied:

Unfortunately, I cannot find the original posting quoted above, since that would probably reveal where the actual usage of perl is.

Generally, we've been trying to not make perl a prequisite for the kernel build, and I'd like to keep it that way. Except for some arch specific stuff I don't really care about, the uses of perl are for the optional "make checkconfig" etc. (which btw look mostly obsolete and should probably be killed), and for generating some firmware, though by default a shipped version of the generated files is used.

Jeff Garzik said that trying to keep Perl out of the kernel was pretty much impossible at that point, because klibc would soon be merged and had Perl dependencies. He said, "perl will indeed be a build requirement for all platforms..."

There was a general outcry at this, and some folks who said Perl would be fine with them. J.A. Magallon objected to the whole thing, saying:

So in short, kernel people:

instead of

I really do not understand...

There were several replies to this, and a couple posts down the road Jeff said:

The fact of the matter is, the area of build tools matters most to people who cross-compile their kernels, because every tool is generally hand-built rather than automatically installed on their Linux system. For this audience, as well as the typical non-cross-compiling kernel developer, Perl is on their system.

However, that fact is less significant than the more basic and core argument:

klibc uses perl for text munging. i.e. one of Perl's acknowledged strengths. This is not a case of choosing a favorite script language, but instead a case of choosing "the right tool for the job." Regardless of whether you think Perl is line noise :) or not, from a technical basis Perl is clearly superior to sed+awk in this case.

Therefore, any rewrite of _this_ _particular_ script in C or shell script would be willfully choosing a sub-optimal implementation language for this task. If you take into account the fact that the overwhelming majority of the target audience does indeed have Perl on their system, then that only serves to make it more clear that any such perl-to-C rewrite would not be on any technical nor practical basis at all.

Adding some final thoughts, perl is already used in nooks and crannies in the build system. Instead of being motivated to stomp those out, please [respectfully!] consider that the Perl scripts might be there because an evaluation of the best tool for the job took place. script_asm.pl in drivers/scsi is a favorite example here.

H. Peter Anvin followed up on this:

To emphasize things a bit further, Perl is:

a) good at munging text;
b) available on basically all development systems;
c) not host- or target-specific.

Thus, I cannot see it as being an issue, and I challenge anyone to find a machine on which they regularly build kernels which doesn't have Perl. Like it or not, today it's as much a part of a general-purpose Unix platform as sed or awk.

Yes, you can write complete shit code in Perl. You can write shit code in any language (Perl does, however, make it easier, so if you're programming in Perl you need to watch out for this.) Yes, you can require 47 different obscure interdependent modules which were just released last week on CPAN, but you can require an equivalent number of obscure libraries in C. Doing that, or require features only available in very recent versions of Perl, would be wholly inappropriate for the kernel build. My personal rule of thumb is that it should work at least as far back as Perl 5.004.

There is one klibc script which possibly ought to be rewritten, and that is the one that uses Digest::MD5 which may not be available on some very old platforms. If so, I'd probably just include the MD5 digest code in the script itself, rather than having to deal with C code that is compiled for the host in the klibc tree.

11. Kernel Ironies

2 Feb 2003 - 3 Feb 2003 (2 posts) Archive Link: "irony"

People: Jeff GarzikRobert L. Harris

Jeff Garzik said, "The definition of irony? Setting one's xscreensaver to BSOD, and then hours later the Linux box has a kernel panic... with the Windows blue screen of death on the screen." Robert L. Harris replied, "A guy I used to work with at a Major insurance company in Denver Colorado saw the BSOD one day. From about 30 feet away he stopped, looked at it and then me. "You know, I thought you were running windows for a second but then realized the font was wrong..." He was very serious."

 

 

 

 

 

 

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