Kernel Traffic
Latest | Archives | People | Topics 		Wine
Latest | Archives | People | Topics 		GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Kernel Traffic #36 For 27 Sep 1999

By Zack Brown

Table Of Contents

Introduction

A number of people didn't like the intrusiveness of the left nav bar, especially for printing, so we're working on a format for a printable version of KT and the Cousins. I haven't replied personally to most of those emails, but I really appreciate and encourage them.

Mailing List Stats For This Week

We looked at 1206 posts in 4645K.

There were 451 different contributors. 194 posted more than once. 155 posted last week too.

The top posters of the week were:

1. PCI Probing

10 Sep 1999 - 15 Sep 1999 (46 posts) Archive Link: "[patch] pci probing"

Topics: PCI

People: Jeff Garzik, Alan Cox, Linus Torvalds

Jeff Garzik said:

PCI probing in drivers really sucks. The attached patch against 2.3.18 is small, self-contained, and should be incredibly valuable to PCI driver writers. I myself have duplicated this code in no less than _four_ drivers.

My patch adds a PCI probing function which takes an array of PCI ids (typically __initdata tables in a driver), and probes for each in turn. It calls a callback function to do the actual registration work. The architecture is very flexible, and should be useful to most people supporting drivers with more than one chipset, or more than one board.

Can we sneak this small, totally-zero-impact, easy-to-review, tested patch in? ;-)

Linus Torvalds (on his way out the door for his 2.5 week vacation) said the patch looked good but wouldn't be applied now; but Alan Cox was against the patch, saying that Don Becker had a more flexible, cleaner solution, that all PCI network drivers were going to move to. Jeff didn't see how Don's work was more better, and after a brief exchange with Alan, Jeff merged the work together. There followed a good bit of implementation discussion, in which Don also participated.

2. ISAPnP ne2k Clone Included In ne.c Driver

11 Sep 1999 - 15 Sep 1999 (6 posts) Archive Link: "[PATCH] support for ISAPnP code with ne2000 network driver"

People: Richard Guenther, Alan Cox

Richard Guenther posted a patch to support initializing a ISAPnP ne2k clone with the ne.c driver; he added, "Unfortunately, deactivating the card at module unload seems to be impossible (or at least hard) due to a lack of a private field in struct net_dev. At least it works for me, but probably other ID's have to be added to the isapnp card list." Alan Cox pointed out that there was a simple way to handle that problem, and Richard posted another patch that used that method to deactivate the card at module unload.

3. Support For MODULE_PARAM As Kernel Command Line Argument

11 Sep 1999 - 15 Sep 1999 (16 posts) Archive Link: "[PATCH][RFC] support for MODULE_PARAM as kernel commandline"

Topics: Sound

People: Richard Guenther, David Hinds

Richard Guenther posted a patch to transform MODULE_PARAM declarations into appropriate __setup() functions, to allow built-in modules to get their parameters from the kernel command line. This allowed him to prevent ISAPnP from stealing his soundcard IRQ. David Hinds was very excited about the patch, but had some implementation issues regarding naming conflicts on the boot command line, since each module had its own name space. There were questions about how to handle any sort of correction that would be implemented, and a discussion followed in which various schemes were presented.

4. Illegal asm Breaks Some Compilers

12 Sep 1999 - 14 Sep 1999 (12 posts) Archive Link: "2.2.13-pre6 build failed (gcc-2.95.1)"

Topics: Assembly

People: Ivan Kokshaysky, Horst von Brand

Sergey Kubushin reported some compile errors using the new gcc 2.95.1; Horst von Brand targetted it as some illegal asm in the kernel, and Ivan Kokshaysky posted a patch that "would make all versions of gcc happy." Sergey posted the locations of several other places in the code that had illegal assembly. Ivan suggested contacting the maintainers of the particular drivers, and Horst concluded, "Trouble is, the usage of clobbering an input sounds quite reasonable, the correct way to do it is unintuitive. And worst of all, it works (sort of) with gcc-2.7.x. So the error goes on..."

5. Linux On A SparcServer 4/490

13 Sep 1999 - 14 Sep 1999 (12 posts) Archive Link: "Linux on a SparcServer 4/490?"

Topics: Disks: SCSI

People: Anton Blanchard

Jussi Hamalainen got a Sun SparcServer 4/490 and wanted to know how well Linux would run on it, if at all. After a bit of discussion, the conclusion drawn by many was, not yet. Anton Blanchard summed up the problem, saying the Sun would have to merge in their VME SCSI code, and there would have to be support added for the memory management unit (mmu) before Linux would run on it.

6. Linux 2.3.18ac3 Announced

14 Sep 1999 (1 post) Archive Link: "Linux 2.3.18ac3"

Topics: Kernel Release Announcement, PCI, SMP, USB

People: Alan Cox, Tigran Aivazian, Tim Waugh, Artur Skawina, Richard Guenther, Andrea Arcangeli, Jeff Garzik, Jean Tourrilhes, Mikael Pettersson

Alan Cox announced 2.3.18ac3, saying:

The big ones here are the new config files. They are now consistent about EXPERIMENTAL. Driver authors please check if you think the tagging is right. Its now consistent, but the old values were not so at times David has guessed which of the several counterclaims you meant.

Also the MODULE_PARM change should clean up __setup stuff for many people. Some drivers have MODULE_PARM inside ifdef MODULE at do not want it now, some vice versa.

He posted the changelog:

2.3.18ac3

7. Incremental -ac Patches

14 Sep 1999 (3 posts) Archive Link: "incremental ac patches"

People: Andrea Arcangeli, Alan Cox

Andrea Arcangeli asked:

I'll raise this issue before the 2.3.18 ac patches will grow to mbytes in size ;).

Would it be possible to make the 2.3.18ac patches as incremental (as the pre-2.2.0?) and not every time against the official 2.3.18? It would avoid me to waste some time and bandwith ;).

Alan Cox said he hoped his patches didn't get to be so large, and added that it would be a pain to generate incremental patches, but invited anyone who pleased, to do so. Robert Brooks volunteered, if someone would upload them to kernel.org. End Of Thread.

8. Andrea Arcangeli's Patch Set

14 Sep 1999 (1 post) Archive Link: "my-2.3.18ac3"

Topics: Version Control

People: Andrea Arcangeli

Andrea Arcangeli posted URLs to his FTP areas on e-mind.com and suse.com, and announced:

I have some pending patch for 2.3.x and as I am running 2.3.x I am forced to take these patches in sync until they will be merged in order to run them on my machine. Instead of making a new big andrea-patch as I did in the past, now I am going to take all patches sparated. This way is really ugly for running controlversial patches since if two of my patches will be controversial I'll have to maintain two version of one of the two patches: one plain against the official kernel always ready for kernel inclusion and another secondary patch that will apply clean on the top of my kernel tree. But this is the only way since taking everything into a CVS repository reduce to zero the time to merge a new kernel reveision, but it make too much hard to cleanly extract the single patches leather.

Since I'll do this patch-work for me I believe it's a good idea to make it public so everybody can test my stuff without having to apply eventually controversial patches by hand from linux-kernel etc...

9. Resetting The Keyboard Rate

14 Sep 1999 - 15 Sep 1999 (4 posts) Archive Link: "Keyboard IOCTL's"

People: Vojtech Pavlik

Mario Goegel was sharing his keyboard between two machines via a manual switch, but found that his key-press repeat rate would slow down whenever he made the switch. Vojtech Pavlik suggested:

Try my new input drivers, at http://www.suse.cz/development/input, those will automatically restore the repeat rate (and leds) when you plug (switch) the keyboard back in.

Or, alternately, open the switch box, and solder the power anf ground line to just one of the inputs, this way the keyboard won't reset its settings when you switch between the servers.

10. The Development Process Criticized

14 Sep 1999 - 16 Sep 1999 (53 posts) Archive Link: "Accountability"

Topics: Feature Freeze, Networking, Software Suspend, Version Control

People: Colin McCormack, Martin Mares, Alan Cox, Miquel van Smoorenburg, Jamie Lokier, Steve Dodd, Linus Torvalds

Colin McCormack gave a pointer to the EPCKPT checkpointing utility page, and asked why EPCKPT wasn't in the kernel yet. He added, "it's quite good, its functionality can't be duplicated in user space, and it has some quite useful applications."

Some folks took exception to the idea that the functionality of EPCKPT couldn't be duplicated in user-space. Martin Mares said:

One day I wrote ftp://atrey.karlin.mff.cuni.cz/pub/local/mj/linux/freezer-0.0-pre2.tar.gz which is a simple checkpoint/restart utility completely in userspace, but it lacks several important features like saving/restoring of FPU registers and signal handler.

Some weeks later Ondrej Filip <feela@ipex.cz> has filled in the missing bits. His version is available at ftp://ftp.ipex.cz/pub/local/feela/src/freezer.tgz.

Jamie Lokier explained there was a feature freeze, meaning no new features in the kernel until 2.5, but Colin replied that the patch had been around since 2.0.36. Several folks pointed out that the author of the patch (not Colin) had not tried to get the patch incorporated, and that Linus Torvalds couldn't be expected to search for good patches.

Alan Cox's advice was, "I would suggest the first thing you want to do is to port it to 2.3.x and make it work on 2.3.x. If you can get it stable, clean and solid when 2.4.x appears then it is both a good add on patch and its positioned nicely to go into 2.5.x . I plan to do the same with the extremely useful swsuspend patch for example."

Miquel van Smoorenburg explained some aspects of the development process:

Kernel patches need to be announced on linux-kernel. Then you get a few people to test it. Then you send it to the subsystem maintainer, or directly to Linus. These people are very busy; if you sent a patch for 2.3.15 and in the main time 2.3.18 has appeared on which it doesn't patch cleanly you won't get an answer. Also if you don't document _very well_ what the patch does and why it won't get applied either.

If Linus or the subsystem maintainer doesn't reply assume your patch was not good enough. You can send another email to ask for an explanation, and you'll usually get one.

To get a patch in the kernel, you need to be very persistent. OTOH, as soon as a you get a driver or filesystem or other subsystem into the kernel of which you are clearly the author/maintainer, patches will usually be applied with no questions asked.

Alan and Colin skirted the edges of anger for awhile. Other folks started getting annoyed at Colin as well, and he gave this analysis:

In reading Steve Dodd's post, among others, a few key realizations occurred, for me.

1) The mailing list linux-kernel *is* the change repository.

This is precisely how comp.sources.minix worked, all those years ago: if you followed the newsgroup you knew everything there was to know about Minix, if you didn't you knew nothing.

2) Only patches to unstable kernels will ever be considered for inclusion in a kernel.

Not unreasonable, when you think about it, but not obvious either, unless you read this mailing list.

3) The patch submission process is ad-hoc and informal.

Or, perhaps, it seems that way to someone who's not actually primarily focused on the kernel. Over time rules of thumb have arisen such as whom not to flame, what format to submit patches in, which ideas are Hot' and which will languish.

You can predict a lot from this and a few subsidiary observations.

First: only kernel-centric patches will flourish, because only people who follow the group will be able to negotiate the caucus, and only people who are primarily focused on the kernel will bother.

Second: any kernel functionality which forms a sufficiently large and modular chunk will have to spin off and use its own resources, as has happened with MM and with ISDN. The traffic flow in the main list will swamp anything that's not primarily focused on the kernel.

Third: the kernel list won't ever see a real pressing need for a CVS because they're comfortable with the list's use as a patch repository.

Some folks pointed him to the FAQ, others explained in various ways their understanding of how kernel development took place. Eventually Colin stopped posting and the discussion petered out.

11. Linux On The RS6000

14 Sep 1999 (4 posts) Archive Link: "Linux for a PPC"

Nuno F Ferreira asked if Linux would work on IBM's RS6000, and Erik Bennett said yes and gave a pointer to YellowDog Linux.

12. Abit BE6's HPT366 UDMA66 Controller Support

14 Sep 1999 (2 posts) Archive Link: "Support for Abit BE6's HPT366 UDMA66 controller?"

Topics: Disks: IDE

People: Andre Hedrick

Andrew Mann asked what the status of Abit BE6's HPT366 UDMA66 controller support was, and Andre Hedrick replied, "You can not currently use the second ATA-66 channel under Linux. Unless you have a rabbit in the hat to register/service/handle the interrupt assignment to pin B for the second channel, it will lockup regardless. The interrupt is not serviced correctly. This will be on all mainboards that have native onboard support."

13. 2.2.13pre8 Announced

15 Sep 1999 (1 post) Archive Link: "Linux 2.2.13pre8"

Topics: FS: NFS, Networking, PCI

People: Alan Cox, Karsten Keil, Ingo Molnar, Paul Gortmaker, G. Allen Morris III, Paul Fulghum

Alan Cox released 2.2.13pre8 and posted the changelog:

2.2.13pre8

14. 2.3.18ac4 Announced

14 Sep 1999 - 15 Sep 1999 (4 posts) Archive Link: "Linux 2.3.18ac4"

People: Alan Cox, David Weinehall, Andrea Arcangeli, Paul Fulghum

Alan Cox released 2.3.18ac4 and posted the changelog:

2.3.18ac4

15. NFS Errors In 2.2.12

14 Sep 1999 - 15 Sep 1999 (2 posts) Archive Link: "NFS related log messages in 2.2.12...."

Topics: FS: NFS

People: Trond Myklebust

Luke Miller was seeing a "NFS: can't silly-delete" error on his NFS client under 2.2.12 with linux-2.2.7-sunrpc.patch, nfsd-2.2.7-2.lockd.patch, nfsd-2.2.7-3.patch, and nfsd-2.2.7-nfsfh.patch applied. Trond Myklebust explained:

This is due to a bug in the current silly-delete code (that prevents files from being deleted while some other process is keeping it open).

Currently, the deletion is attempted done by the last closing process regardless of whether that process has the allowed permissions. Furthermore, as in the above case, signals from the closing process affect the outcome of the silly-delete (so killing the process with 'kill -9' will typically result in the above error).

I've got a plan for a fix which I'll hopefully get round to soon (I'm concentrating on doing the rewrite of the NFSv3 write code at the moment) In case somebody fancies a spot of DIY, there's a short description of the general idea in point 5) of http://www.fys.uio.no/~trondmy/src/TODO

16. SNA Protocol For Linux

15 Sep 1999 (1 post) Archive Link: "SNA"

People: Folkert van Heusden

Folkert van Heusden gave a pointer to his SNA For Linux page. SNA is a network protocol for communicating with mainframes.

17. Login Prevented On 2.3.18ac4

15 Sep 1999 - 16 Sep 1999 (4 posts) Archive Link: "cannot login after 2.3.18ac4"

People: Alan Cox

Someone found that with 2.3.18ac4, he could no longer log in to his machine. After doing a floppy reboot, he found that mingetty was putting a "tty1: invalid character" error in the log. Alan Cox asked him to back out the changes to drivers/char/tty_io.c and include/linux/tty.h, from ac4 back to ac3, to see if that would help; this was tried and didn't work. However, recompiling with GCC 2.95.1 (after applying the usercopy.c patch) did work.

18. USB Status

15 Sep 1999 - 16 Sep 1999 (5 posts) Archive Link: "State of USB drivers"

Topics: Disks: SCSI, Modems, Networking, USB

People: Michael T. Babcock, Drew Bernat, Johannes Erdfelt, Johannes

Dagan Sgiath asked how well USB was doing under Linux, and Michael T. Babcock replied, "I used the drivers when they were a kernel add-on to the 2.1.x and 2.2.x series and they worked fine for most people for USB mice and keyboards. I don't know about the stability of them at this stage though." Drew Bernat added, ""Popular" (my definition of it :) devices work well. By that, I mean things like keyboards, mice, hubs. Audio devices are being worked on, as are cameras. UPSs and other power devices are being worked on. Ethernet adapters are on the list, and we're getting some support. Parallel and serial converters are nonstandard, proprietary, and not supported." Johannes Erdfelt replied, "You missed HP scanners, Modems and Floppies (SCSI)" but pointed out, "Parallel devices are NOT proprietary. USB Printers are Parallel to USB convertors and have a spec behind them." He also added that the stack had changed since 2.1.x

19. 2.3.18ac5 Announced

16 Sep 1999 - 19 Sep 1999 (10 posts) Archive Link: "Linux 2.3.18ac5"

Topics: Disks: IDE, Kernel Release Announcement, Networking, PCI, USB

People: Alan Cox, Richard Guenther, Jens Axboe, Johannes, David Hinds, Giacomo Catenazzi, Pauline Middelink, David Parsons, Stephen Tweedie

Alan Cox announced 2.3.18ac5, adding, "Ok give this a spin. We need to sort out the modules/setup argument thing yet. Preferred patches against this one are compile fixes, warnings, driver locking fixes and the like." He posted the changelog:

2.3.18ac5

Pauline Middelink reported that this kernel now thought she had 8 tulip cards in her machine (she only had one), and Alan said this was a bug in the new pci-scan code with regard to resource checks/allocation.

To Alan's original announcement, Richard Guenther said:

Note that a fix using MODULE_NAME() _will_ break the current semantics of some modules:

now, well if its easy, I'll look into it.

He and Alan then briefly discussed implementation details.

20. CBMFS v. 0.4e Announced

16 Sep 1999 (1 post) Archive Link: "[Announcement] CBMFS v0.4e"

People: David Weinehall

David Weinehall gave a pointer to his patch page and announced:

For anyone interested, I've just put a unified diff patch with CBMFS v0.4e on my homepage. This one should work, as opposed to my previous v0.4's... It compiles without warnings (thus it's good), the computer boots with it compiled into the kernel (thus it's better) and the filesystem mounts and doesn't oops on cp/ls etc. (thus it's perfect)

Autodetection works (at least for the disk-images I've tried), and the birds are singing outside my window (ok, that's a lie.)

21. PCMCIA Merging Into Linus Tree

16 Sep 1999 (1 post) Archive Link: "Comments on status of PCMCIA merge"

Topics: Feature Freeze

People: David Hinds

David Hinds explained:

To answer a few questions that have been popping up about this...

First some history: Linus did the first crack at merging PCMCIA into the kernel tree on his own before he left on vacation, and some things were left in an unfinished state. I think he mainly just wanted to be able to say it was in there before the feature freeze.

There is still lots of stuff in the standalone PCMCIA package that is not in the kernel tree. Only a few client drivers are in the kernel tree at this point... the rest will hopefully migrate in soon. Some things may not make it into the kernel any time soon (specifically, the PnP BIOS add-ons). Also, the user-mode tools in the PCMCIA package, like cardmgr, are (at least for now) essential for using PCMCIA and will never be part of the kernel tree. So, moving some parts of PCMCIA into the kernel does not affect the need for the standalone package. The only immediate benefit to having PCMCIA in the kernel tree is that some components can be linked into the kernel (whether this is much of a benefit is debatable, I guess).

Alan's 2.3.18ac5 patch updates a lot of the changes that Linus made, to make it easier for me to maintain a common code base for the standalone and in-kernel PCMCIA distributions. This patch *should* fix the Makefile problems (I guess the raw 2.3.18 did not build as modules, and ac3 only built as modules, but ac5 should build either way).

For now, the vast majority of people should probably continue to use PCMCIA as they did before, using the standalone package, and ignore the kernel PCMCIA support until it settles down and more clients are merged in.

22. 2.2.13pre9 Announced

16 Sep 1999 - 18 Sep 1999 (4 posts) Archive Link: "Linux 2.2.13pre9"

Topics: Kernel Release Announcement

People: Alan Cox, Ivan Kokshaysky, Andrea Arcangeli

Alan Cox announced 2.2.13pre9 and posted the changelog:

2.2.13pre9

Andrea Arcangeli listed a lot of fixes from him that had not made it into the release, and gave a URL to them. Alan went over the list, applying many of them and rejecting various others, saying that it looked like 2.2.13pre10 would be the "Andrea Special".

23. Alan Warns Against New GCC

17 Sep 1999 - 20 Sep 1999 (11 posts) Archive Link: "Re: 2.2.13 & gcc-2.95.1"

People: Alan Cox

In the course of hunting down compile errors, Alan Cox said, "Please dont build production kernels with gcc 2.95.x. For fun yes, work no."

24. Long-Time Memory Corruption Bug Fixed

18 Sep 1999 - 19 Sep 1999 (2 posts) Archive Link: "Memory corruption with 2.3.18"

People: Pete Zaitcev, Theodore Y. Ts'o

Pete Zaitcev posted a one-liner to fix some memory corruption (&secret+3 had been used instead of &secret[3]), adding, "I cannot believe nobody hit it before, I must have missed a linux-kernel thread. &secret+3 produces a pointer at three sizes of the array away and way over the array boundaries."

Theodore Y. Ts'o replied, "Good catch! Yup, that's definitely a problem. I have no idea how we've gone so long without anyone catching this, since the problem exists in the 2.2 kernels as well."

 

 

 

 

 

 

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.