Kernel Traffic #204 For 7 Feb 2003

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

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.

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

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

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.

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

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

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.

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

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

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

Pete Zaitcev asked about a post from the previous day 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:

do not want perl in the kernel build
allow qt to pollute the kernel to have a decent gui config tool
have to rewrite half perl features in C
but perl will be needed anyways

instead of

do all parsing in perl, that is what perl is for and what is mainly done in kconfig scripts
do the config backend in perl, and...
do the gui in perl-XXX, so you can have perl-GTK, perl-GTK2, perl-QT or perl-Tk, even perl-Xaw (so you get rid of tcl/tk)

I really do not understand...

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.

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.

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


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

1.	21 Jan 2003 - 29 Jan 2003	(9 posts)	Replacing pcihpfs With sysfs
2.	25 Jan 2003 - 31 Jan 2003	(9 posts)	IDE Heading Toward Hotplugging Support
3.	26 Jan 2003 - 30 Jan 2003	(3 posts)	Status Of VISWS Support
4.	28 Jan 2003 - 31 Jan 2003	(7 posts)	An Attempt To Gain Permission To LGPL Parts Of The Kernel
5.	28 Jan 2003 - 30 Jan 2003	(20 posts)	Secure Distribution Of New Kernel Sources
6.	29 Jan 2003 - 4 Feb 2003	(2 posts)	Updating The Boot Sector Code
7.	30 Jan 2003	(1 post)	New Smatch Bug Hunter And Database
8.	31 Jan 2003 - 3 Feb 2003	(2 posts)	Status Of SquashFS
9.	31 Jan 2003	(1 post)	Status Of Startfire Network Driver In 2.4
10.	31 Jan 2003 - 1 Feb 2003	(22 posts)	Perl In The Configuration System
11.	2 Feb 2003 - 3 Feb 2003	(2 posts)	Kernel Ironies

Kernel Traffic #204 For 7 Feb 2003

By Zack Brown