Kernel Traffic #204 by Zack Brown
[email protected] Sun, 09 Feb 2003 18:57:54 -0800
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <E18i48o-0002WY-00@renegade> |
Kernel Traffic #204 For 7 Feb
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 21 Jan - 29 Jan (9 Replacing pcihpfs With sysfs
posts)
2. 25 Jan - 31 Jan (9 IDE Heading Toward Hotplugging Support
posts)
3. 26 Jan - 30 Jan (3 Status Of VISWS Support
posts)
4. 28 Jan - 31 Jan (7 An Attempt To Gain Permission To LGPL Parts
posts) Of The Kernel
5. 28 Jan - 30 Jan (20 Secure Distribution Of New Kernel Sources
posts)
6. 29 Jan - 4 Feb (2 Updating The Boot Sector Code
posts)
7. 30 Jan (1 post) New Smatch Bug Hunter And Database
8. 31 Jan - 3 Feb (2 Status Of SquashFS
posts)
9. 31 Jan (1 post) Status Of Startfire Network Driver In 2.4
10. 31 Jan - 1 Feb (22 Perl In The Configuration System
posts)
11. 2 Feb - 3 Feb (2 Kernel Ironies
posts)
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:
* 38 posts in 108K by Alan Cox
* 36 posts in 95K by John Bradford
* 25 posts in 322K by Martin Schwidefsky
* 21 posts in 57K by Raphael Schmid
* 20 posts in 77K by Andrew Morton
* Full Stats
1. Replacing pcihpfs With sysfs
21 Jan - 29 Jan (9 posts) Archive Link: "[PATCH] Replace pcihpfs with sysfs."
Topics: FS: sysfs
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 - 31 Jan (9 posts) Archive Link: "[PATCH] Update PnP IDE (2/6)"
Topics: Disks: IDE
People: Adam Belay, Andre Hedrick, Alan 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 - 30 Jan (3 posts) Archive Link: "[PATCH] visws support for 2.5.59"
Topics: VisWS
People: Andrey Panin, Christoph 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 - 31 Jan (7 posts) Archive Link: "Permission to use atomic code under
LGPL"
People: Christian Fredrik Kalager Schaller, Pavel Machek, Russell King,
Christoph 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 - 30 Jan (20 posts) Archive Link: "kernel.org frontpage"
People: H. Peter Anvin, Kasper Dupont, Chris Friesen, Valdis Kletnieks, Russell
King, John 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 - 4 Feb (2 posts) Archive Link: "[UPDATED PATCH] Removal of boot
sector code"
People: H. Peter Anvin, Mikael 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 (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
[email protected] (mailto:[email protected]) 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 - 3 Feb (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 (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 - 1 Feb (22 posts) Archive Link: "Perl in the toolchain"
People: Pete Zaitcev, Kai Germaschewski, Jeff Garzik, J.A. Magallon, H. 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:
+ 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...
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 - 3 Feb (2 posts) Archive Link: "irony"
People: Jeff Garzik, Robert 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."
We Hope You Enjoy Kernel Traffic
Kernel Traffic is hosted by the generous folks at Tux.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.