There was a bit of an implementation discussion following the announcement of knfsd 1.5; H. J. Lu, while not the maintainer of the patch (there's actually no official maintainer) does put out releases now and then for his own use. This time, someone had sent him some patches against a previous version, and H. J. replied asking for a more uptodate version to include in his next release, since he had already included some patches from David Woodhouse which conflicted with these new submissions.

Neil Brown pointed out that David's patches had not really been intended to be included in an official release, and were more a work-in-progress. According to him, David intended to tidy them up soon, but until then they should not be used. He also gave a pointer to David's and his thoughts on the direction for the patch culled from private email and various lists.

H. J. replied with some patches, in light of the new situation, and Neil had some criticism and suggestions. He summed up the problem as he saw it, with, An NFS file handle has xdev and xino entries which indicate which export entry is being used. If mountd is to give an NFSEXP_NEGATIVE entry to the kernel to reject a given file handle, it needs to know this xdev/xino information somehow. Currently it doesn't (unless, by luck, xdev/xino is the root file the filesystem). It is only given the device, and the path to the actual file which is being accessed and went on to describe his own ideas for a solution. H. J. thought these represented too divergent a direction, and chose a different method, closer to what he had done originally. Neil had a whole bunch of problems with H. J.'s solution, and posted a long description of problems he'd found in the latest release. There followed some further implementation discussion. At one point, H. J. said, I see 1.5.x as alpha. Nothing is final yet. The reason I like it is it gets rid of /var/lib/nfs/rmtab. However, that means we have to find a way for kernel to communicate to mountd. Maybe RPC is a better choice. Anyone wants to implement it?

Later, under the Subject: A new Linux/NFS mailing list, H. J. gave a pointer to the subscription page of a new discussion list.

Later, under the Subject: knfsd 1.5.x and 1.4.x, H. J. said, As people have found out that knfsd 1.5.x is not as stable as 1.4.x. knfsd 1.5.x should be viewed as alpha. The production system should use 1.4.x. The current one is 1.4.7 and I am planning to make 1.4.7.1 soon.

This Subject was first discussed in . This time, someone pointed out that http://www.svrec.ernet.in/~vijo/tolks/tolks.html, listed in the Documentation/kernel-docs.txt file, was no longer available, and asked if the "Tour Of The Linux Kernel Source" could be found anywhere else. Rik van Riel volunteered to help set up such a thing, and other folks gave links to Linux Cross Reference and the Kernel Hacking HOWTO. Regarding the latter, Tigran Aivazian was offended by the word "fuck" in the title of section 3.1; several folks weighed in on various sides of the issue, and although no solution presented itself on the list, a quick check shows that the word is no longer in the Kernel Hacking HOWTO.

Steven N. Hirsch was still having problems with vmware failing to recognize his cdrom drive. He told Jens Axboe that reverting Jens' patches got rid of the problem. With them in, the problem would still appear from time to time. Jens replied, Sigh. The vmware guys are not answering my mails which makes this issue hard to resolve. He offered to back out the changes that were causing Steven's problem, but Alan Cox interrupted, with, Don't do this. This is the wrong answer for a development kernel. Backing it out means we never find the problem until its too late. Jens replied that he'd just been looking for a quick fix, but in light of Alan's objection, he'd start looking into the problem more forwardly. No solution appeared during the thread.

Mike A. Harris posted an oops he'd gotten from 2.2.11, adding that he'd been using vmware. Alan Cox replied, If you have 3rd party modules loaded then its not a useful oops report. It could be the third party modules. Mike replied, So does that mean that as long as I'm using VMWARE, which is virtually 100% of the time, that if I incur an oops, it is useless and unwanted on l-k because VMWARE _might_ have caused it? Alan replied, Yes.

David S. Miller pointed out that binary-only modules created a black-box situation that strongly interfered with kernel debugging, but Mike corrected him, saying that vmware's modules did indeed come with sources, although they were not GPLed. David replied, I stand corrected, and publicly apologize.

Alan added, Those modules allow vmware itself to do a lot of clever unsafe things behind the kernels back. So we don't have a good way to track what vmware does. We also get a lot of vmware caused crash reports. Even with the modules for those small bits it is impossible for anyone but the vmware people to debug such a crash. All I ask people to do is to not load vmware from a boot up (system or modules) and duplicate the crash. Then I can debug it

Riley Williams asked if anyone knew how to set up a mobile phone that was supported using Linux's IRDA suite. Marc Mutz gave a pointer to The Linux IrDA Project homepage, adding that the IR-HOWTO linked from there, discussed at least the Ericsson SH888 and Nokia 6110; but Harald Milz pointed out, 6110 doesn't work yet. You need a mobile with a built-in hardware modem. The Ericsson is one of them. Nokia 8110 should work too. If you don't want to pay the premium, a GSM capable modem like the Xircom Realport or those from Option work just fine with most mobiles and a cable. I have the realport and a Nokia 6150, works just great.

Derek J. Balling gave a pointer to a Microsoft article that pointed out Windows' superiority to Linux. There were some disagreements with the factual quality of the article, and Rik van Riel volunteered to collect "annotations" and put them up on the web.

Bernard Wei made the following plea:

He was not the only one who felt the discussion was either pointless, detrimental, or off-topic. But at least one post made it to the list, criticizing many of the points made in the article. Bernhard Rosenkraenzer replied to Rik's suggestion:

Steven N. Hirsch and Henrik Olsen were quick to point out that Bernhard was wrong in item 2 of his first list: ACL's were not in the official kernel (although there were patches floating around). Andreas Gruenbacher gave a pointer to the POSIX Access Control Lists (ACLs) for Linux page.

I pointed out that David Mandala noticed that Red Had had changed the format of the version.h file. It had previously contained the kernel versioning information, but now contained pre-processor commands that would yield the proper versioning information if the pre-processor was run, but would break any package that relied on a simple "grep" or other tool to determing the kernel version from version.h; Bernhard Rosenkraenzer defended the change, and pointed out that 'autoconf', for instance, still worked fine with it. But Ben Collins replied, It seems to have added one more complexity that isn't standard on other systems, however. So now when users manually upgrade their kernel, and things break, we will have to ask them, "are you using that redhat > 6.1? did you upgrade your kernel headers in /usr/include/{linux,scsi,asm}?"

Bernhard replied, People manually upgrading their kernel don't have the modified version.h, because /usr/include/linux should be a symlink to /usr/src/linux/include/linux in any case... but Miquel van Smoorenburg groaned, Argh please not _that_ discussion again. On my (Debian) system, /usr/include/linux is _not_ a symlink to /usr/src/linux/include/linux and hasn't been for ages.

H. Peter Anvin gave a pointer to The Linux Kernel Archives OpenPGP Signature, adding, I'm posting this here to maximize distribution and minimize the risk of a spoof, today or in the future. Sorry for being semi-offtopic. The Linux Kernel Archives authentication key has changed; we are now using an OpenPGP key compatible with GnuPG and PGP 5/6. The new key and the old key revokation certificate are attached, and are always available at http://www.kernel.org/signature.html and from common PGP key servers.