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.

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.

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.

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.

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

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.

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.