Kernel Traffic #154 For 18 Feb 2002

By Zack Brown

Table Of Contents

Introduction

It's now possible to view the full mailing list stats for any given issue, not just the first few. The last entry of each stats section is now a link to the full set. Let me know if you find any problems.

Mailing List Stats For This Week

We looked at 1651 posts in 6999K.

There were 479 different contributors. 240 posted more than once. 226 posted last week too.

The top posters of the week were:

1. 2.5 Configure.help Cleanup

29 Jan 2002 - 7 Feb 2002 (8 posts) Archive Link: "Configure.help in 2.5.3-pre6"

People: Robert LoveLinus TorvaldsDavid LangThomas Capricelli

Ben Clifford noticed that the recent attempt to split up the old Configure.help file into many little files, had broken 'make menuconfig' in the 2.5 kernels. He solved it locally by concatenating all the config files together, and asked if that was the intended fix. Robert Love replied, "The intention is to fix [menu|x]config. I believe plain 'ol `make config' works. The new per-config.in config.help is here to stay." And Linus Torvalds added:

Yes. On the other hand, if there are real problems with converting menu/x config to multiple help-files, a short-term answer might indeed be just the silly "concatenate everything into the same file".

I'd much _prefer_ to have somebody who knows menuconfug/xconfig (or just wants to learn). I have a totally untested patch for menuconfig, that probably just works (like the regular config thing it doesn't actualy take _advantage_ of pairing the Config.help files up with the questions, but at least it should give you the help texts like it used to).

I don't know tcl/tk _at_all_, so I haven't even looked at what the required syntax is for header.tk to use the same kind of "find . -name Config.help" thing.

He posted a patch, which didn't work for Robert, and David Lang said, "well since the old config stuff was just broken it sounds like the perfect time to put in the new stuff rather then wasting time fixing the old, right ;-)" And Thomas Capricelli said grinning, "yeps, yeps and yeps !"

2. Ext Filesystem Corruption Under 2.5.3

5 Feb 2002 - 8 Feb 2002 (15 posts) Archive Link: "Warning, 2.5.3 eats filesystems"

Topics: Disks: IDE, FS: devfs, FS: ext2

People: Heinz DiehlAlexander ViroPavel Machek

Pavel Machek reported filesystem corruption with 2.5.3, which was then cofirmed by several other folks. In particular, Heinz Diehl said, "I bet it _is_ 2.5.3 and not a relict from a 2.5.3-pre patch because I switched directly from 2.4.17 to 2.5.3 without ever using any pre patch at this machine." Alexander Viro pricked up his ears and asked, "Which filesystems are mounted (other than ext2) and are you been able to reproduce it on 2.5.3-pre6?" Heinz and Pavel posted their list of mounted filesystems, which were, respectively:

/dev/hda1 on / type ext2 (rw)
proc on /proc type proc (rw)
/dev/hda6 on /usr type ext2 (rw)
/dev/hda5 on /home type ext2 (rw)
/dev/hdb5 on /var/spool/news type ext2 (rw)
tmpfs on /dev/shm type shm (rw)
tmpfs on /tmp type tmpfs (rw)
tmpfs on /var/tmp type tmpfs (rw)

and

none on /proc type proc (rw)
none on /proc type proc (rw)
none on /proc type proc (rw)
/dev/hda3 on /suse type ext2 (rw)
none on /proc type proc (rw)
none on /proc/bus/usb type usbdevfs (rw)
/dev/cfs0 on /overlay type coda (rw)

Heinz added, "I installed 2.5.3-pre6 and the machine runs for about 6 hours now (heavy load) and no error occured yet." Pavel suspected the trouble was in the IDE code, and later confirmed this by experiment. He posted a warning that IDE under 2.5.3 could cause filesystem corruption.

3. Linus Continues BitKeeper Test

5 Feb 2002 - 13 Feb 2002 (56 posts) Archive Link: "linux-2.5.4-pre1 - bitkeeper testing"

Topics: Compression, Disk Arrays: RAID, Disks: IDE, FS: NFS, FS: ReiserFS, FS: devfs, Ioctls, Networking, PCI, SMP, USB, Version Control

People: Linus TorvaldsLarry McVoyRik van RielRoman ZippelAdrian BunkStelian PopSteven ColeFlorian WeimerDavid ChowAndreas DilgerOliver NeukumOlaf DietscheIgmar PalsenbergDavid Brownell

Linus Torvalds gave an update on his BitKeeper experience so far:

Ok, I've spent about a week trying to change my working habits and scripting bitkeeper enough to (a) import a good revision controlled tree into it from the 2.4.x and 2.5.x patch-archives and (b) try to actually accept patches directly into bitkeeper.

Quite frankly, so far it has definitely made me slower - it took me basically a week to get about 50 patches applied, but most of that time by far was writing scripts and just getting used to the thing. Thanks to Larry and Wayne for helping out with the problems I had.

And I'm not even done yet. I expect to be a bit slower to react to patches for a while yet, until the scripts are better.

However, some of it pays off already. Basically, I'm aiming to be able to accept patches directly from email, with the comments in the email going into the revision control history. For a first example, the ChangeLog file for 2.5.4-pre1 is rather more detailed than usual (in fact, right now it is _too_ detailed, and I haven't written the scripts to "terse it down" for postings to linux-kernel, for example).

The long-range plan, and the real payoff, comes if main developers start using bk too, which should make syncing a lot easier. That will take some time, I suspect.

He included the following automatically generated summary of the 2.5.4-pre1 changes:

ChangeSet@1.220, 2002-02-05 18:36:47-08:00, torvalds@penguin.transmeta.com
defconfig:
update

ChangeSet@1.219, 2002-02-05 18:31:49-08:00, torvalds@penguin.transmeta.com
Makefile:
Update version

ChangeSet@1.218, 2002-02-05 18:03:32-08:00, vojtech@suse.cz

The patch moves:

I don't think the joystick drivers should stay in char, because they're NOT character device drivers (check for register_chrdev, none to be found).

It also fixes build problems with sound driver gameport support.

ChangeSet@1.217, 2002-02-05 17:50:12-08:00, kai@tp1.ruhr-uni-bochum.de
[PATCH] 2.5.3 ISDN work around buggy hw

the appended patch works around a bug in the PLX9050 chip. This chip is used in various PCI ISDN adapters (it's an PCI interface chip) and has an erratum when the BAR 0/1 has bit 7 set (the size of the region is 0x80, so aligning it to 0x80 is legal and really happens for people).

This workaround has been tested by a user who hit this problem with a Gazel card. Basically the same fix has been done for Elsa cards, but it's untested.

ChangeSet@1.216, 2002-02-05 17:50:08-08:00, kai@tp1.ruhr-uni-bochum.de
[PATCH] 2.5.3 ISDN hisax_fcpcipnp driver fix

the appended patch fixes a problem where the ->rcvidx variable was not initialized properly.

ChangeSet@1.215, 2002-02-05 17:50:04-08:00, kai@tp1.ruhr-uni-bochum.de
[PATCH] 2.5.3 ISDN undefined behavior fix

the appended patch fixes a case of undefined behavior, found by Urs Thuermann and "VDA".

ChangeSet@1.214, 2002-02-05 17:50:00-08:00, kai@tp1.ruhr-uni-bochum.de
[PATCH] 2.5.3 ISDN charge hup fix

the appended patch by Igmar Palsenberg fixes the CHARGE_HUP functionality (automatically hang up just before the next charging unit)

ChangeSet@1.213, 2002-02-05 17:49:56-08:00, kai@tp1.ruhr-uni-bochum.de
[PATCH] 2.5.3 ISDN devfs fix

the appended patch by Adrian Bunk removes yet another leftover from the /dev/isdnX devices (which causes an build error when CONFIG_DEVFS_FS=y).

ChangeSet@1.212, 2002-02-05 17:41:43-08:00, nkbj@image.dk
[PATCH] Two fixes for linux-2.5.3.

Correct typo in Documentation/Changes. Remove duplicate code in arch/i386/boot/bootsect.S.

ChangeSet@1.211, 2002-02-05 17:24:28-08:00, vandrove@vc.cvut.cz
[PATCH] crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

I've found that multiple level initcalls went into kernel behind my back, so you can throw away my yesterday patch which converted lib.a => lib.o, and apply this one.

[Patch tested with both lib.a and lib.o - it boots correctly in both cases]

ChangeSet@1.210, 2002-02-05 17:24:24-08:00, vandrove@vc.cvut.cz
[PATCH] Re: [PATCH] nbd in 2.5.3 does not work, and can cause severe damage when read-write

Linus, this reverts limit for request size from 10KB to unlimited. Although no released nbd version supports it, it is certainly better to add support to servers than cripple clients if incompatibility does not matter.

ChangeSet@1.209, 2002-02-05 17:24:21-08:00, trond.myklebust@fys.uio.no
[PATCH] Drop reliance on file->f_dentry in NFS reads/writes

Following a request by David Chow on linux fsdevel, this patch causes NFS read and write requests to take the inode from page->mapping->host rather than relying on file->f_dentry->d_inode. Apparently this will simplify some work he is doing on another filesystem.

In any case, it cleans up the current mix of sometimes doing one thing, sometimes the other (historical cruft), and puts NFS client behaviour on par with what is done in other filesystems...

ChangeSet@1.208, 2002-02-05 17:24:18-08:00, trond.myklebust@fys.uio.no
[PATCH] Fix spurious ETXTBSY errors due to late release of struct file

The following patch should fix a problem of ETXTBSY sometimes occurring if one tries to run a file straight after compilation.

The problem is that both NFS read and write requests can currently hold a count on the struct file. This is done partly so as to be able to pass along the RPC credential (which is cached in the struct file), and partly so that asynchronous writes can report any errors via the file->f_error mechanism.

The problem is that both the read and write requests may persist even after file close() occurs. For O_RDONLY files, this is not a problem, but for O_WRONLY, and O_RDWR files, the fact that the struct file is not released until the last call to nfs_release_request() means that inode->i_writecount does not necessarily get cleared upon file close().

The following patch fixes both these issues.

- NFS read requests no longer hold the struct file. They take a count on the the RPC credential itself.

- NFS write requests still hold the struct file, since they want to report errors to sys_close() using the file->f_error mechanism. However they are made to release the page, credential, and file structures as soon as the write is completed instead of following the current practice of waiting for the last nfs_page request release.

ChangeSet@1.207, 2002-02-05 17:24:14-08:00, trond.myklebust@fys.uio.no
[PATCH] NFS lookup code rewrite w/o open(".") fix...

This is a resend of the NFS lookup code rewrite, but with the open(".") VFS fix removed. (I'll resend the 'uses d_revalidate()' version separately after a suitable delay to allow for comments.)

Issues fixed by this patch:

ChangeSet@1.206, 2002-02-05 17:17:24-08:00, greg@kroah.com
[PATCH] USB ohci-hcd driver update

Here's a patch against 2.5.3 for the USB ohci-hcd driver that does the following:

This patch was done by David Brownell.

ChangeSet@1.205, 2002-02-05 17:17:21-08:00, greg@kroah.com
[PATCH] USB vicam driver update

Here's a patch against 2.5.3 for the USB vicam driver that removes the use of interruptible_sleep_on() in the driver. This patch was done by Oliver Neukum.

ChangeSet@1.204, 2002-02-05 17:17:18-08:00, greg@kroah.com
[PATCH] USB core update

Here's a patch against 2.5.3 for the USB core that fixes a possible initialization bug for some platforms when allocating a new usb, and changes the warning level on a message (it isn't an error.) This patch was done by Oliver Neukum and David Brownell.

ChangeSet@1.203, 2002-02-05 17:17:14-08:00, greg@kroah.com
[PATCH] USB stv680 driver update

Here's a patch against 2.5.3 for the USB stv680 driver that fixes two bugs in the existing driver. This patch was done by Kevin Sisson.

ChangeSet@1.202, 2002-02-05 17:17:11-08:00, greg@kroah.com
[PATCH] USB printer driver update

Here's a patch against 2.5.3 for the USB printer driver that does the following:

This patch was done by Oliver Neukum.

ChangeSet@1.201, 2002-02-05 17:17:08-08:00, greg@kroah.com
[PATCH] USB pegasus driver update

Here's a patch against 2.5.3 for the USB pegasus driver that does the following:

This patch was done by Petko Manolov and Oliver Neukum.

ChangeSet@1.200, 2002-02-05 17:17:05-08:00, greg@kroah.com
[PATCH] USB Kaweth driver update

Here's a patch against 2.5.3 for the USB kaweth driver that does the following:

This patch was done by Oliver Neukum.

ChangeSet@1.199, 2002-02-05 17:17:02-08:00, greg@kroah.com
[PATCH] USB Config.help update

Here's a patch against 2.5.3 that updates the Config.help entries for the USB microtek and hpusbscsi drivers. This patch was done by Oliver Neukum.

ChangeSet@1.198, 2002-02-05 17:16:58-08:00, greg@kroah.com
[PATCH] USB Kawasaki driver maintainer change

Here's a patch against 2.5.3 that changes the maintainer of the USB Kawasaki driver to Oliver Neukum.

ChangeSet@1.197, 2002-02-05 17:11:07-08:00, reiser@namesys.com
[PATCH] reiserfs patchset, patch 9 of 9 09-64bit_bitops_fix-1.diff

09-64bit_bitops_fix-1.diff
Bitopts arguments must be long, not int.

ChangeSet@1.196, 2002-02-05 17:11:04-08:00, reiser@namesys.com
[PATCH] reiserfs patchset, patch 8 of 9
08-unfinished_rebuildtree_message.diff

08-unfinished_rebuildtree_message.diff
Give a proper explanation if unfinished reiserfsck --rebuild-tree run on a fs was detected.

ChangeSet@1.195, 2002-02-05 17:11:00-08:00, reiser@namesys.com
[PATCH] reiserfs patchset, patch 7 of 9 07-remove_nospace_warnings.diff

07-remove_nospace_warnings.diff
Do not print scary warnings in out of free space situations.

ChangeSet@1.194, 2002-02-05 17:10:57-08:00, reiser@namesys.com
[PATCH] reiserfs patchset, patch 6 of 9 06-return_braindamage_removal.diff

06-return_braindamage_removal.diff
Kill stupid code like 'goto label ; return 1;'

ChangeSet@1.193, 2002-02-05 17:10:54-08:00, reiser@namesys.com
[PATCH] reiserfs patchset, patch 5 of 9
05-kernel-reiserfs_fs_h-offset_v2.diff

05-kernel-reiserfs_fs_h-offset_v2.diff
Convert erroneous le64_to_cpu to cpu_to_le64

ChangeSet@1.192, 2002-02-05 17:10:50-08:00, reiser@namesys.com
[PATCH] reiserfs patchset, patch 4 of 9 04-nfs_stale_inode_access.diff

04-nfs_stale_inode_access.diff
This is to fix a case where stale NFS handles are correctly detected as stale, but inodes assotiated with them are still valid and present in cache, hence there is no way to deal with files, these handles are attached to. Bug was found and explained by Anne Milicia <milicia@missioncriticallinux.com>

ChangeSet@1.191, 2002-02-05 17:10:47-08:00, reiser@namesys.com
[PATCH] reiserfs patchset, patch 3 of 9 03-key_output_fix.diff

03-key_output_fix.diff
Fix all the places where cpu key is attempted to be printed as ondisk key

ChangeSet@1.190, 2002-02-05 17:10:44-08:00, reiser@namesys.com
[PATCH] reiserfs patchset, patch 2 of 9 02-prealloc_list_init.diff

02-prealloc_list_init.diff
prealloc list was forgotten to be initialised.

ChangeSet@1.189, 2002-02-05 17:10:40-08:00, reiser@namesys.com
[PATCH] reiserfs patchset, patch 1 of 9 01-pick_correct_key_version.diff

01-pick_correct_key_version.diff
This is to fix certain cases where items may get its keys to be interpreted wrong, or to be inserted into the tree in wrong order. This bug was only observed live on 2.5.3, though it is present in 2.4, too.

ChangeSet@1.188, 2002-02-05 16:36:53-08:00, mochel@osdl.org
[PATCH] driver model updates (5/5)

Remove struct iobus.

There is a lot of duplication between struct device and struct iobus, both in their members and the code in their interfaces. Waxing struct iobus removes this duplication and makes things a bit simpler.

ChangeSet@1.187, 2002-02-05 16:36:53-08:00, mochel@osdl.org
[PATCH] driver model updates (4/5)

Patch 4: Add some default files for PCI devices.

This adds two files for PCI devices: 'irq' and 'resources'. They display just those things and currently do nothing on write. These are the examples for other subsystems to use for creating files ('Hey, look how simple it is!')

ChangeSet@1.186, 2002-02-05 16:36:52-08:00, mochel@osdl.org
[PATCH] driver model updates (3/5)

Patch 3: Make default callbacks simpler.

I want to move as much to a 1 file/1 value model as possible. I haven't come up with a clean way to enforce it except via social pressure.

This patch is a step in that direction. It:

ChangeSet@1.185, 2002-02-05 16:36:51-08:00, mochel@osdl.org
[PATCH] driver model updates (1/5)

Patch 1: Make device_driver_init() an initcall. It declares it as subsys_initcall and removes the explicit call from init/main.c::do_basic_setup().

ChangeSet@1.184, 2002-02-05 16:36:50-08:00, mec@shout.net
[PATCH] fix xconfig for new help system

Here is a patch to enhance xconfig to read the new Config.help files. Olaf Dietsche wrote this, and Steven Cole passed it on to me.

Testing: Steven Cole tested it, and I tested it.

ChangeSet@1.183, 2002-02-05 16:36:50-08:00, knan@mo.himolde.no
[PATCH] typo in drivers/scsi/megaraid.h

A trivial patch that fixes this irritation in my dmesg, 2.5.3:

megaraid: v1.18 (Release Date: Thu Oct 11 15:02:53 EDT 2001) <5>megaraid: found 0x8086:0x1960:idx 0:bus 2:slot 5:func 1 scsi0 : Found a MegaRAID controller at 0xe089c000, IRQ: 12

Please apply.

ChangeSet@1.182, 2002-02-05 16:36:49-08:00, vandrove@vc.cvut.cz
[PATCH] nbd in 2.5.3 does not work, and can cause severe damage when read-write

Hi Linus,

I've got strange idea and tried to build diskless machine around 2.5.3... Besides problem with segfaulting crc32 (it is initialized after net/ipv4/ipconfig.c due to lib/lib.a being a library... I had to hardcode lib/crc32.o before --start-group in main Makefile, but it is another story) there is bad problem with NBD caused by BIO changes:

(1) request flags were immediately put into on-wire request format. In the past, we had 0=READ, !0=WRITE. Now only REQ_RW bit determines direction. As nbd-server from nbd distribution package treats any non-zero value as write, it performs writes instead of read. Fortunately it will die due to other consistency checks on incoming request, but...

(2) nbd servers handle only up to 10240 byte requests. So setting max_sectors to 20 is needed, as otherwise nbd server commits suicide. Maximum request size should be handshaked during nbd initialization, but currently just use hardwired 20 sectors, so it will behave like it did in the past.

ChangeSet@1.181, 2002-02-05 16:36:49-08:00, twaugh@redhat.com
[PATCH] 2.5.3-pre6: mode

This patch paves the way for a new driver which needs the functionality. Now parport_daisy_select actually _uses_ its mode parameter.

ChangeSet@1.180, 2002-02-05 16:36:48-08:00, twaugh@redhat.com
[PATCH] 2.5.3-pre6: deadlock

This patch fixes a potential deadlock in ppdev.

ChangeSet@1.179, 2002-02-05 16:36:47-08:00, twaugh@redhat.com
[PATCH] 2.5.3-pre6: console

I finally found the reason that printer console sometimes acted up (duh):

* drivers/char/lp.c: Fix printer console.

ChangeSet@1.178, 2002-02-05 16:36:47-08:00, twaugh@redhat.com
[PATCH] 2.5.3-pre6: getmodes

This patch prevents ppdev from oopsing when the PPGETMODES ioctl is used before a PPCLAIM.

* drivers/char/ppdev.c: Fix an oops in PPGETMODES handling.

ChangeSet@1.177, 2002-02-05 16:36:46-08:00, twaugh@redhat.com
[PATCH] 2.5.3-pre6: ecr

This patch (from 2.4.x) cleans up the use of the ECR in parport_pc.

ChangeSet@1.176, 2002-02-05 16:36:45-08:00, davem@redhat.com
[PATCH] Sparc updates

Gets sparc64 in sync with 2.5.3 final changes.

ChangeSet@1.175, 2002-02-05 16:36:44-08:00, davem@redhat.com
[PATCH] Missing ZLIB export

ChangeSet@1.174, 2002-02-05 16:36:44-08:00, davem@redhat.com
[PATCH] Fix UFS build

Missing smp_lock.h inclusion.

ChangeSet@1.173, 2002-02-05 16:36:43-08:00, davem@redhat.com
[PATCH] malloc.h references

linux/malloc.h --> linux/slab.h

ChangeSet@1.172, 2002-02-05 16:36:42-08:00, davem@redhat.com
[PATCH] Fix typo in i386 PCI header

I made a typo the other weeks while renaming the interfaces for you, oops. Please apply, thanks.

ChangeSet@1.171, 2002-02-05 16:36:42-08:00, davem@redhat.com
[PATCH] OSST kdev_t fixes

MINOR --> minor
MKDEV --> mk_kdev

ChangeSet@1.170, 2002-02-05 16:36:41-08:00, davem@redhat.com
[PATCH] Fix IDE printf formatting

The usual "u64 is long long only on some platforms" problem.

ChangeSet@1.169, 2002-02-05 16:36:40-08:00, davem@redhat.com
[PATCH] Fix ESP thinko in 2.5.3-final

I think I told you to revert this bit from 2.5.3, but here it is in patch form anyways. Whoever made this change didn't read the driver, and well... didn't even build test it either :-)

ChangeSet@1.168, 2002-02-05 16:36:40-08:00, davem@redhat.com
[PATCH] Dup in drivers/net/Config.in

Don't offer SunLANCE twice.

Several folks said that they'd actually prefer seeing these full patch listings rather than shorter summaries.

At one point, Larry McVoy also said:

I've put up read-only clones on

http://linux.bkbits.net

you can go there and get the changelogs in web form. I just figured out what a bad choice 8088 was for a port and we'll be moving stuff over to 8080 since that seems to go through more firewalls.

hpa is working on getting these up in some of the kernel.org sites, he's stalled out because of some stuff he needs from me, we'll get that straightened out and the the authoritative source is bk.kernel.org or master.kernel.org, I'm not quite sure. Peter will tell you. But we'll keep up to date with Linus' BK tree as long as he is playing with BK and you can follow along there.

Oh, and for what it is worth, I agree that having the changelogs as part of the history rocks. Goto the http://linux.bkbits.net:8088/linux-2.5 link and click on user statistics - because Linus hacked up a nice email to patch importer script, all the patches look like they were checked in by the person who sent them. And it propogates down to the annotated listings.

Elsewhere, Florian Weimer expressed concern that BitKeeper might become mandatory for subsystem maintainers, in the sense that folks not using BitKeeper might have to wait longer for their patches to be applied. Rik van Riel replied, "They're pretty much equally easy to deal with, except that the bitkeeper patches will always apply and will get better changelog entries."

Elsewhere, Roman Zippel apparently objected that the whole "feature" of including email info in the changelog could be handled by a script. Linus agreed that this could have been scripted, and added that actually all his email went through a script anyway, before going into BitKeeper. But he added, "The advantage is mainly that (a) you can generate this changeset listing yourself, and not limit it to the stuff I merged and (b) when the developers I work with start sending me their bitkeeper merges _as_ bitkeeper merges and we start having the advantage of various tools to help resolve conflicts." Roman replied that actually, he just meant the whole business of accepting patches directly from email. He said, "Pine supports piping a mail to a script, this script could try to apply the patch and extract the text in front of the patch, but it could of course also recognize a bk patch and feed it to bk. The important thing is to avoid two classes of patches, bk patches and patches, which would create extra work for you. It would be no problem to use tags, which can be easily extracted by above script, just tell us, how they should look like." Linus said that actually, this was not the problem he was having. He explained:

The problem I have with piping patches directly to bk is that I don't like to switch back-and-forth between reading email and applying (and fixing up) patches. Even if the patch applies cleanly (which most of them tend to do) I still usually need to do at least some minimal editing of the commit message etc (removing stuff like "Hi Linus" etc).

So my scripts are all done to automate this, and to allow me to just save the patches off for later, and then apply them in chunks when I'm ready to switch over from email to tree update. So that's why I script the thing, and want to apply patches from emails rather than by piping them.

Some of these issues don't exist with true BK patches, and I'm trying to set up a separate chain to apply those directly (and not from the email at all - the email would contain only a description and a BK repository source). That will be very convenient for multiple patches, but at the same time that will require more trust in the source, so I'll probably keep the "patches as diffs in emails" for the occasional work, and the direct BK link for the people I work closest with.

Stelian Pop asked how this would affect people who only sent the occassional patch to Linus, but who also used BitKeeper. Linus replied, "For those people, "bk send -d torvalds@transmeta.com" is fine. It ends up being close enough to a regular patch, and I'm hoping that Larry will change the syntax slightly so that it won't be so ugly." but Larry pointed out that the actual command had to be "bk send -d -r+ torvalds@transmeta.com" to send the most recent cset. The command Linus had given would send the entire repository. Stelian felt this mistake would probably happen. He added that he'd like to be asked for comfirmation when sending anything via BitKeeper. Andreas Dilger agreed.

4. New Kernel Installation Script

7 Feb 2002 (5 posts) Archive Link: "Linux Kernel Information & Install Kernel Script"

People: Justin PiszczJ.A. MagallonH. Peter Anvin

Justin Piszcz announced:

New site: http://www.installkernel.com/. It is very light at the moment.

  1. Latest news about the kernel:

    http://www.installkernel.com/kernel.html

    Anything else I should add under 2.4.17?

  2. Install Kernel (bash script which I am working on)

    http://www.installkernel.com/ik/index.html

ik-0.8.9: Adds -b option, you can build and install the kernel from the current directory with -b.

Summary of ik:

Install Kernel (ik) is a bash script that installs the Linux kernel and automatically sets up LILO or GRUB.

It also saves your kernel configuration each time you do an install. This allows you to restore the newest configuration file when you make a new kernel. This script is intended for two groups of people; people new to compiling kernels, and people who are tired of moving files around and editing their bootloader configurations every time they install a new kernel.

H. Peter Anvin suggested that Justin make this work as /sbin/installkernel, but Justin replied, "Perhaps, however I began ik in December 2000. No /sbin/installkernel existed at the time. And /sbin/installkernel doesn't support grub on my rh72 box. Nor does it check dependencies, etc, etc." H. Peter replied that installkernel had existed since around 1993; and J.A. Magallon added, "You should really take a look at /sbin/installkernel from Mandrake. Bootloader autodetection (lilo-grub), old kernel backup, adds entries in loader config file... a bunch of features. Do not reinvent the whell."

5. 2.4.18-pre9

7 Feb 2002 - 9 Feb 2002 (10 posts) Archive Link: "Linux 2.4.18-pre9"

Topics: Clustering, Disks: SCSI, FS: ReiserFS, FS: devfs, Framebuffer, Ioctls, Networking, PCI

People: Marcelo TosattiTill Immanuel PatzschkeManfred SpraulJens AxboeMartin KnoblauchAdrian BunkDavid S. MillerJames SimmonsOleg DrokinRobert SchwebelStelian PopAlan CoxRussell KingJeff GarzikKai GermaschewskiAndrew MortonBjorn Wesen

Marcelo Tosatti announced 2.4.18-pre9:

So here it goes.

pre9:

Till Immanuel Patzschke asked, "is there any chance for including the latest PPP patch from Paul (2.4.2 - 20020205) and Michael's pppoe patch 0.6.10 -- only those "two" patches eliminate the PPP deadlocks! Might be worth putting these into 2.4.18 final ? :-)" Marcelo replied, "Unfortunately, no. Such patches should be integrated in early -pre series. 2.4.19-pre-early will probably have Paul's PPP fixes."

6. Killing Processes From Sysrq

8 Feb 2002 - 11 Feb 2002 (6 posts) Archive Link: "Sysrq enhancement: process kill facility"

People: Lamont GranquistPete Zaitcev

Someone posted a patch to extend sysrq to provide a way to manually kill processes, by giving "alt-sysrq-n" (for nuke) and providing the process ID. Pete Zaitcev felt this was pure bloat, and suggested just using kdb to debug the kernel. But Lamont Granquist put in:

Its very useful to have adequate debugging tools for productions systems. Something like SGIs kdb is too heavyweight and is not in the mainline linux kernel and will never, ever get pushed out to any of the production systems that I work on. However, useful alt-sysrq tools to do post-mortem analysis of crashed production kernels is something which is extremely helpful.

What would be *really* useful would be to have crash dump functionality in the mainline linux kernel. That way you could take a dump and then do your post-mortem offline with a debugger. Until then I'm all in favor of throwing bloat into alt-sysrq, since that seems to be Linus' preferred interface for doing post-mortem analysis.

7. Email Address Confusion

8 Feb 2002 - 9 Feb 2002 (19 posts) Archive Link: "Linus' email account is full. - Fwd: Mail System Error - Returned Mail"

Topics: Spam

People: H. Peter AnvinDavid GarfieldRoss VandegriftAnton AltaparmakovLinus Torvalds

Anton Altaparmakov reported that Linus Torvalds' email account at Transmeta appeared to be over quota, causing email to bounce! About a million and a half people pointed out that Anton had sent his mail to the wrong address: torvalds@transmet.com (note the missing 'a'). H. Peter Anvin said, "apparently someone is being a "scalper" and trying to capture peoples misaddressed email. This is getting to be a very painful problems for a lot of organizations." But David Garfield replied:

Actually, I suspect the situation is somewhat simpler. It is possible transmet.com may only have one mailbox that everything funnels into. Their mail is hosted by "registeredsite.com", which has a somewhat invalid web presence (IP address = 10.0.0.1).

From transmet.com's web site, the company appears to be manufacturer of metal flakes, and does not appear to have a particularly large web presence.

And Ross Vandegrift put in, "Interesting. In my battles against spam, a *HUGE* precentage has been linked with registeredsite.com. Wouldn't be surprised if they were harvesting addresses, or some other such vile stuffs."

8. MODULE_LICENSE Value For Public Domain Code

8 Feb 2002 (4 posts) Archive Link: "What "module license" applies to public domain code?"

People: Mark E. CarsonAlan Cox

Mark E. Carson asked:

There was a discussion awhile ago which touched briefly on this, but I didn't see a resolution, so...

I am writing kernel module code which must (for various reasons) be public domain. Given that, are any of the module license strings in include/linux/module.h appropriate for it?

I checked the version in the 2.5.3 kernel tree, and the best I could come up with was "GPL and additional rights." However, I couldn't find any precise definition of this anywhere, so I'm not sure it's really correct here. It'd be kind of a perverse definition of "public domain," in any case.

Of course, anyone else would be free to take the code and apply any license whatsoever to it, but my concern is simply what MODULE_LICENSE() line I can legitimately include, if any.

Alan Cox replied:

We have to be careful about this because MODULE_LICENSE("Public domain") doesn't mean anything if the resulting code is then shipped binary only. GPL and additional rights is probably closest or even just a

/*
* When linked into the Linux kernel the resulting work is GPL, you
* are however free to use this work under other licenses if you
* so wish. See README.blah
*/

MODULE_LICENSE("GPL"); /* When part of Linux */

9. Submitting BitKeeper Patches

8 Feb 2002 (2 posts) Archive Link: "Submitting BK patches..."

Topics: Version Control

People: Jeff GarzikLinus Torvalds

Jeff Garzik asked Linus Torvalds:

Here's modifying my patch submission method a bit. I have taken my pending changes for you, and split them up into different BK clones. Each tree represents a different patch "theme", for different types of patches being submitted to you: net driver maintenance stuff is at http://gkernel.bkbits.net/net-drivers-2.5, filesystem-related stuff can be stored at fs-2.5, small driver fixes at small-fixes-2.5, etc. This gives you a more fine grain from which to 'bk pull'.

It also makes it easier on me as a maintainer, because I can (for example) continue to push boring maintenance patches to net-drivers-2.5, which leaving more controversial or unrelated trees untouched. If you want to ignore net driver merges for a couple weeks, I can keep pushing release-quality stuff to net-drivers-2.5, and then you can just 'bk pull' all the acculumated stuff.

In order to keep the community better in the loop, I'll post the commented changeset summaries you get, as well as full GNU-style patches for any changes worth comment. (in the near future, I'm hoping I can provide a URL to a plaintext GNU-style patch for each changeset, making this stuff even more accessible to non-BK users)

The next two e-mails are examples which are ready to be merged. All BK changes from me are now under their own URL, http://gkernel.bkbits/... You'll note the "pull from" URL at the top of each changeset e-mail.

Comments and questions (from all) welcome... I'm hoping this sort of system will (a) make merging and review easier for you, (b) make ongoing maintenance easier for me, and (c) keep all these changes visible and easily available to people not using BK.

Linus replied, "This sounds very good, exactly how I want to work."

10. Marcelo And BitKeeper

12 Feb 2002 - 13 Feb 2002 (2 posts) Archive Link: "Marcelo & bk ?"

Topics: Version Control

People: Marcelo TosattiThomas Capricelli

Thomas Capricelli asked if Marcelo Tosatti would be using BitKeeper for 2.4 maintenance, and Marcelo replied, "I have to take a closer look and learn how to use it first. Rik already tried to get me to do that, though I haven't found time yet."

11. Status Of eepro100 Driver

13 Feb 2002 (4 posts) Archive Link: "Eepro100 driver."

Topics: BSD, Patents

People: Jeff GarzikBen GreearDonald BeckerAndrew Morton

Clustering: Beowulf

Someone asked about the status of the EEPro100 driver. There appeared to be two versions of it in the kernel sources, for some reason, one by Donald Becker, and one by Andrey V. Savochkin. Donald's version appeared to be lagging behind the sources available at his web page (http://www.scyld.com/network/eepro100.html) . The poster asked why this was so, and if the driver had forked. Jeff Garzik replied that the code had forked a long time ago, and that the reason Donald's code was not being kept uptodate in the kernel was "a political one, Mr. Becker doesn't like us :) He has refused to send patches for any kernel, for a long time now." He added, "Long term, it" [the driver] "is going to be replaced with e100 from Intel, as soon as that driver is in good shape." Ben Greear asked when this might happen; and added, "In the past, I heard there were licensing problems, have those been cleared up?" Jeff replied that the ETA was "Soon but not terribly soon. Intel has been responsive to feedback from Andrew Morton and myself. Once it passes our review and Intel's testing, it will go in. eepro100 will live on for a while, until we are certain e100 is stable, though. (and eepro100 won't disappear from 2.4 at all)" For the licensing issue, he added, "Things are looking hopeful on this front. e1000 is going to be submitted for inclusion into the kernel soon, reportedly with a GPL / BSD + patent grant license. e100 should follow suit. This hasn't happened yet, so I don't want to say "yes" for sure..."

 

 

 

 

 

 

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.