Jeremy Elson of Sensoria Corporation unwittingly solved a large piece of the WinModem problem under Linux. He announced FUSD version 1.00, explaining, FUSD lets you write user-space daemons that can respond to device-file callbacks on files in /dev. These device files look and act just like any other device file from the point of view of a process trying to use them. When the FUSD kernel module receives a file callback on a device being managed from user-space, it marshals the arguments into a message (including data copied from the caller, if necessary), blocks the caller, and sends the message to the daemon managing the device. When the daemon generates a reply, the process happens in reverse, and the caller is unblocked. He gave a link to the FUSD homepage.

After some bug reports that showed FUSD had been prematurely released as 1.00 (possibly due to its corporate sponsorship), Pavel Machek suggested forwarding the announcement to the linmodem mailing list, adding, Killing all those binary-only modem drivers from kernel modules would be good thing... Hmm, and maybe we can just hack telephony API over ltmodem and be done with that. That would be good. Jeremy asked, Perhaps I don't understand how linmodems work to understand well enough how FUSD would apply - do you talk to linmodems through the serial driver? If so, sounds like a good application - but we might still have the same problem with binary-only drivers as the user-to-kernel message format used by FUSD may change over time. (Indeed, it's already changing relative to v1.0 in response to some of the mail I've gotten in the past few days.) Pavel confirmed, regarding whether linmodems used the serial port, Yep. And linmodem driver does signal processing, so it is big and ugly. And up till now, it had to be in kernel. With your patches, such drivers could be userspace (where they belong!). But he (and others) were not happy to hear that the interface would be changing over time. Jeremy Explained:

Elsewhere, Eric W. Biederman asked for a fuller explanation of how FUSD could be useful to linmodems, and Jeff Garzik replied:

Pavel added, One of students here was/is working on the glue; it is non-trivial as 'modem' is obfuscated with coroutines. And Tim Jansen gave a link to the (somewhat stale) 'modem' page. He also added, This is also important for USB modems. As Intel requests PC vendors to stop including serial ports in 2002 and linux-compatible USB modems are quite hard to find it will be really difficult to get an external modem for new computers. Almost every new USB modem uses either the ST7554 or the Connexant HCF chipset, and at least the ST7554 is controllerless.

Morgan Collins noticed that his kernel was being marked as 'tainted' with non-free modules, because the PPP compression module carried the BSD license. Alan Cox and David Woodhouse said this was a bug. As David put it, Any code which is distributed as part of the kernel source tree has a sane, if not 100% compatible, licence and shouldn't taint your kernel. But Keith Owens put in, Any license not listed in include/linux/module.h is not GPL compatible. He gave this list (from 2.4.11) as:

• "GPL": [GNU Public License v2 or later]
• "GPL and additional rights": [GNU Public License v2 rights and more]
• "Dual BSD/GPL": [GNU Public License v2 or BSD license choice]
• "Dual MPL/GPL": [GNU Public License v2 or Mozilla license choice]

The BSD license on its own was not part of the list, so (he implied) the PPP compression should mark the kernel tainted. David felt it was silly not to include the BSD-NAC (no-advertisement-clause), and Alexander Viro also felt the LGPL should also be included. Keith said the current list had been created by Alan Cox, and Alan also said:

This didn't make sense to David, who pointed out that a patent could also restrict distribution of GPLed code. He added, Either way, I didn't think that a political stance against patents was the point of the kernel tainting code - I thought it was about maintainability. He went on:

An unidentified person suggested that modules could simply lie about their licensing and bypass these safeguards altogether, but Alan replied, under the DMCA thats probably a criminal offence with five years in jail. The truth however is that if you want to lie about licensing or run a modutils that doesn't do it nobody stops you. Its there primarily to deal with bug filtering from people who don't know better. Folks who know enough to subvert the mechanism generally also know better than to post Nvdriver bugs to l/k. Andreas Dilger pointed out that all anyone had to do was edit their ksymoops output to not display the "tainted" flag, and added, I don't think we need to be mucking with "GPL vs. BSD" or anything, but rather "source available or not" as the criterion for a tainted module. Heaven forbid that using some driver currently in the kernel sources marks your kernel as tainted, it would make the whole thing useless.

At one point Andreas Ferber suggested, What about simply adding "BSD (included in kernel)" as a possible "untainted" MODULE_LICENSE()? Alan liked the idea, and Henning P. Schmiedehausen suggested "BSD (included in kernel source)" as showing source availability. Pekka Pietikeinen added, Or even something like "BSD (unmodified source freely available)", which would cover 3rd party drivers as well. Close by, someone suggested simply including a flag to indicate source availability, but Alan said, Available under what terms, NDA'd, subject to unacceptable other rules etc.. Its not as simple as it looks.

The discussion petered out around there, with no firm decisions either way.

Rik van Riel announced:

Several folks were interested in this, and at one point Andrea Arcangeli said, Later, if you've some time to test, I'd also be very interested in a comparison with 2.4.12aa1. A little later, John L. Males said:

Lorenzo Allegrucci also ran his own tests:

Bob Matthews reported an oops under 2.4.11; Linus Torvalds identified the problem and asked if anyone could come up with a patch. Alan Cox replied, Ingo did patches for -ac a long time back. I've not submitted them since it simply didnt seem an important matter when prioritising patches. If you want them I can isolate them tomorrow.

In a completely different thread on a different technical topic, under the Subject: [patch] .version, newversion in Makefile, Rudi Sluijtman reported, Due to a change in the main Makefile the .version file is overwritten by a new empty one since at least 2.4.10-pre12, so the version becomes or remains 1 after each recompile. Russell King replied that there was a patch in the -ac series to fix that, and David S. Miller added, I've also independantly just sent Linus a patch to fix this. I was not aware of the -ac fix, sorry. Russell replied, It was sent around 20 September to Alan, Linus and lkml. Alan accepted it, Linus dropped it, and hardly anyone noticed on lkml. ;( and Alan added (in reply to David), Maybe he'll notice this time. Russell sent him a fix, I sent him Russells fix and now you've sent him a fix 8)

That was the end of that thread. Elsewhere, under the Subject: Uhhuh.. 2.4.12, Linus announced:

He replied to himself shortly thereafter after noticing more breakage, adding, On the other hand, the good news is that I'll open 2.5.x RSN, just because Alan is so much better at maintaining things ;)

Marco Colombo asked, will Alan release 2.4.13 asap with Rik's VM? - (sorry, couldn't resist) Alan replied, I think 2.4.13 will be a Linus release.

Paul Gortmaker found that patching the diff program to read all files into cache before comparing them, would result in a speedup by a factor of five in comparing kernel trees. With the files already in the cache, his patch took a slight performance hit. Linus Torvalds suggested reading in just one directory at a time, to prevent too much memory use. He added, I've for a long time thought about adding a "readahead()" system call. There are just too many uses for it, it has come up in many different areas.. He suggested submitting the patch to the diff maintainer, saying, This change seems small and simple enough that they might accept it, and I'd love to see it. I'll probably do this in my copy anyway, but it would be nicer to not have to patch it specially..

Marcelo Tosatti recalled seeing a USENIX 2001 paper on this subject, entitled Design and Implementation of a Predictive File Prefetching Algorithm. He added, They have a Linux implementation of their complex prediction algo, but I think directory readahead itself makes sense for most stuff.

Elsewhere, Willy Tarreau described an incantation to get very fast diff results:

Horst von Brand pointed out that most editors did not unlink before saving. As far as he knew, only jed did this. Nick Craig-Wood pointed out, emacs does mv file file~ before saving file so the edited file will not be linked byt the backup file will be. You can stop it doing this by setting backup-by-copying-when-linked. Wojtek Pilorz, also apparently using a similar method to Willy, offered:

Patrick McFarland asked why Linus Torvalds had put Andrea Arcangeli's "simple" version of the virtual memory subsystem into the 2.4 kernel, when Rik van Riel's VM code seemed to be kicking ass in Alan Cox's tree. Linus replied, "complex" != "smart". The benchmarks I've seen says that the simple VM performs better - both in terms of repeatability and in terms of absolute performance. Search this list yourself if you don't believe me. Elsewhere, Alan also replied to Patrick, I've not reached any final conclusions on the VM - there are things that Rik's VM shows up that look like the VM algorithm is right but it triggers other stuff, and there are a couple of hackish bits left in still. zSmart is often good - especially given how slow disk seeks are. But smart is not always best for any algorithm.

Elsewhere, Luigi Genoni remarked, I do not care which VM is simpler, nor which is faster. I loock for predictability, since this is the most important thing on the servers I am administering. Under a special situation I need something maybe less predictable, but smarter to manage a stressed system. Rik replied:

Robert Love pointed out that Alan's tree was more stable. Patrick asked why he thought so, and Robert said that Alan's code was not modified as extensively as Linus'. Elsewhere, Rik also said:

Christoph Lameter noticed that 2.4.11 wouldn't load the loop driver, giving an unresolved symbol error with the message, "modules without a GPL compatible license cannot use GPLONLY_ symbols". This made no sense at all to him, since the loop driver came with the kernel and was properly licensed. Keith Owens explained, If a symbol has been exported with EXPORT_SYMBOL_GPL then it appears as unresolved for modules that do not have a GPL compatible MODULE_LICENCE string. So when a module without a GPL compatible MODULE_LICENCE gets an unresolved symbol, I print that message as a hint to the user. I thought the response was obvious, but looks like I need to expand the hint text even further. Christoph reiterated that the loop driver was GPL-compatible, and Keith replied, In 2.4.11 loop.c has no MODULE_LICENCE. It will take a while for all modules to be correctly flagged. A few posts down the line, Ben Greear suggested, Can't you just make it a warning for now and give ppl a few months to clean things up? It strikes me that any code that serves no technical purpose and actively decreases functionality of the kernel is highly suspect. Or maybe even wait till 2.5...