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? ;-)

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.

2.3.18ac3

• Cleaned up the PCMCIA makefiles - now works modular (me)
• Move proc fs documentation into fileysystems (Jeff Garzik)
• Fixed SMP locking for softdog read/write Note in 2.3.x the master kernel lock isnt held for read/write methods on drivers (me)
• Added SMP locking to bw-qcam and bttv Also to some other drivers (eg radio*) (me)
• Fix LAVA PCI idents (Tim Waugh)
• Fix kunmap debug bug (Andrea Arcangeli)
• Kill remaining __init calls (Tigran Aivazian)
• Big config file cleanup (David Weienhall)
• MediaGX audio workarounds (me)
• Set PCI master flags on OHCI USB (me)
• OHCI SMM to native takeover (me)
• Re-enable FOOF fix (Mikael Pettersson)
• Parport fixes (Mikael Pettersson)
• Wavelan fixes (Jean Tourrilhes)
• ParPort init fixes (Tim Waugh)
• ISAPnP for ne2k Someone could generalise the probe table stuff .. (Richard Guenther)
• Export scsi_wait_cmd (Doug Gilbert)
• Errno comment fixes (Artur Skawina)
• Automagical module parameter->setup parser This was broken for non arrays. I think I have it fixed properly. (Richard Guenther)
• Hopefully fixed the Defxx driver (me)

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

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

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.

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.

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.

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.

2.2.13pre8

• Fix PCI/PCI_QUIRKS compile error (me)
• I/O APIC update (Ingo Molnar)
• ISDN update (Karsten Keil)
• SyncLink update (Paul Fulghum)
• PPC Update (Paul Gortmaker)
• QlogicISP fix (Dave Miller)
• Update ctime on rename (Chris Siebenmann)
• NFS generation ids (G. Allen Morris III)
• Fix /proc kstk values (Solar Designer)
• Updated multisound drivers (Andrew Veliath)

2.3.18ac4

• Fix the dumb scsi bug I hope (me)
• Further config updates (David Weinehall)
• SyncLink driver udpate (Paul Fulghum)
• ISOfs fix (Todd Sabin)
• Fix OPL3 compile ("CaT")
• Low memory setup fix (Gerhard Wichert)
• make Xconfig big rework (Andrzej M. Krzysztofowicz)
• Config file fix (Andrzej M. Krzysztofowicz)
• Kupdated (Andrea Arcangeli)
• Merged most of the 2.2.13pre fixes Note non x86 isnt merged, nor most drivers with active maintainers (me)

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

2.3.18ac5

• Davicom DM9102 ethernet driver (Sten Wang, Davicom)
• IDE CD update (Jens Axboe)
• USB CPIA driver update (Johannes Erdfelt)
• Clean up all the si_band signal bugs (Stephen Tweedie)
• Improved ncurses test for dialog build (David Parsons)
• PCMCIA Makefile fixes, resync to tree (David Hinds)
• Menuconfig no longer needs GNU awk (David Parsons)
• PCMCIA makefile fixes (Christof Petig)
• Mixed type/sign and include fixes (Giacomo Catenazzi)
• Some alpha build fixes (James McCollough)
• Moved pci_scan into drivers/pci (me)
• Network driver updates (Don Becker)
  • Tulip 0.91m
  • Yellowfin 1.03a
  • 3c59x 0.99M
  • epic100 v1.07j
  • rtl8139 v 1.08d

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

• we (really) should enforce everyone to have a MODULE_NAME (can we get a default out of __FILE_NAME__ with some tricky macro??)
• some already have a prefix encoded into their arguments (isapnp springs into my mind) - those will have to be ripped off - and it "breaks" backward-compatibility, as the prefixes are not always like "isapnp_"

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

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

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.

2.2.13pre9

• Make shmall configurable + fixed a couple of bugs (Henrik Nordstrom)
• Amateur radio update (Tomi Manninen)
• Tlan unloads if it finds no cards (Christian Holtje)
• ISOfs fix (Todd Sabin)
• Fix Amiga RDSK parsing (Benny)
• Fix signal delivery hole (me)
• Davicom D9102 driver (Sten Wang, Davicom)
• Strlen_user fix I still strongly recommend you don't use gcc 2.95 to build 2.2.13 kernels. There are 3 or 4 reports now of 'random crash' that went away with older compilers. (Ivan Kokshaysky)
• Hopefully fixed the 3c527 properly (me)