NO!

Doing so VIOLATES the terms and agreement that you obtained the BINARY Soft-Raid Engine and the GPL terms of the kernel.

Well, it's not up to just me, given that Linus also has his copyright on the code (although I doubt there's more than a few lines which are originally his). There are some other people who have contributed code to the serial driver in the past, although most have probably not given me more than a dozen lines of code or so, which seems to be the (completely untested in court) standard which the FSF uses to decide whether or not they need to get formal legal papers signed.

The legal issues are also incredibly murky, since the customers create the derived work, and issues of intent aside, you can't necessarily use intent to change the legal definition of "derived work". (Be glad; although it can be used to create a loophole in GPL, just meditate a while on what the MPAA could do with such an "intent" argument before you decide whether or not it's a good thing. Or think what Microsoft could do if they could make their EULA's as infectious as the GPL with the "intent" argument.) The whole dynamic linking argument is a very slippery slope; where do you draw the line? Does a shell script which calls a GPL program get infected? What about a propietary C program which makes a system() call to invoke a GPL'ed bash? What about an RPC call across the network? What about a GNOME Corba interface? Is it OK if it's on separate machines, but are they considered a single program if the CORBA client and server are on the same machine, since now they share the same VM?

In any case, the FSF has their opinion, and at least one Ivy League law professor laughed aloud when he was asked what he thought about the FSF's legal theories; other people have their own. Most importantly, none of this has been tested in court. So it's probably not worth trying to settle this on the linux-kernel list.

As far as this particular case is concerned, at least Lucent is shipping part of the driver in source. Some of the other winmodem drivers are shipping a pure binary module, which means it will only work against a single kernel version, which locks out users form upgrading to newer kernels if they still want to use their winmodem. So at least Lucent is trying to be at least somewhat good guys about this.

I could threaten to sue them, but it's not clear to me what good it will do, short of depriving some users from being able to use their winmodem. I suppose we could encourage them to rewrite the modified-serial.c for scratch, but aside from making some GPL fanatics feel good, enriching some consultant and making Lucent a little poorer, what good does it really do in the long run? And I have better things to do with my time. At the same time, I certainly won't bless what they are doing. What they are doing is clearly wrong, and illegal. But it is an imperfect world that we live in, as the events in Florida have been clearly demonstrating over the past month.

Given the limited time that I have, I'd much rather spend it going after the Rockwell/Connexant winmodem driver, which also pretty clearly uses serial.c, but for which they've only distributed a single .o file for a specific kernel version. Or I could spend it on programming.....

Under the "Doctrine of Inevitable Disclosure" even looking at GPL code and using techniques it contains would contaminate anything someone works on. This doctrine put forward two concepts that have been used in trade secret cases to justify injunctions and non-competes in areas of IP pollution -- negative knowledge and inevitable misappropriation.

The argument goes something like this. Negative knowledge is defined as knowing what techniques do not work (as opposed to what techniques do work). In the course of development of a piece of software, there are many "blind alleys" and "false starts" that are encountered as an individual uses trial and error to perfect whatever piece of software he is writing. Over time, the person learns what approaches are blind alleys and which work. This knowledge becomes imprinted into the actual thinking processes of this person.

Source code can also contain notes and comments about what does not work, and what does work. Someone reading this source code would then incorporate these ideas and knowledge into their thinking processes. Companies spend lots of money paying engineers to develop software, and this "negative knowledge", under the doctrine of inevitable disclosure is legally the property of an employer since they paid an engineer to experiment and learn it. This is how companies are able to get non-compete court orders against employees in trade secret lawsuits -- they argue that noone is going to go down a development path using ideas or approaches they know do not work. This argument goes on to state that if two engineers, one who had access to a piece of code vs. one who did not were to start at the same time working on the same problem, the person who had access to the code would finish first because he would "inevitably use" the knowledge gained from access to the source code.

Let's say for example two engineers wanted to write a new Linux-like replacement. One of them had access to ftp.kernel.org and the other did not. Which one of the engineers would finish first? Obviously the one with access to ftp.kernel.org would finish first and would not have had to use trial and error to get all the IOCTL calls working, etc. The engineer without source code access would take longer, perhaps by a factor of years, to complete the same project.

Under this argument, it is argued that the engineer who had source code access "inevitably used" negative knowledge he gained from his study of the Linux sources. Absent the vague descriptions of what a "derivative work" is in the GPL, it could be argued that conversion of any knowledge contained in GPL code is a "derivative work".

There are a lot of big software companies who believe this and fear application of the doctrine of inevitable disclosure relative to GPL code. Novell and Microsoft both do not even allow employees to bring GPL code into the building -- period -- for fear that someone will attempt to file a claim that they have "converted" GPL code and created derivative works that may have contaminated non-GPL code projects. Novell has an official standing policy barring employees from using GPL code. That's why all the Linux work for NetWare is done in the India development center, and not the US, out of fear of IP pollution in the Provo facility. When I officed at the Microsoft campus in 1999, they had similiar policies, and were even more strict than Novell.

Now, in reality, these folks have employees in both companies who download stuff at home, and putz around with it, GPL code included, but that's a lot different from these companies having official policies allowing projects to use GPL code in their normal course of business.

In short, under the doctrine of inevitable disclosure, a GPL copyright holder could succeed with a claim of conversion from someone simply looking at a piece of GPL code, then using whatever it contained to build either interface modules or a module with similiar functionality. It would be a hard call for a sitting judge to make, but I have seen actual cases where a judge does just that with the help of a special master.

Personally, I think the doctrine is one of the most evil fucking things in existence, legal opponents call it "the doctrine of intellectual slavery" because it has the affect under the law to be able to convert simple NDA agreements into non-compete agreements, and I've seen it used this way. Novell has blocked all internal access to the NWFS ftp server TRG, BTW, because they are afraid I would attempt to apply the doctrine to force them to open source NetWare projects if they download NWFS and used it internally with eDirectory. They've told us so.

This may help you understand just how complicated this whole IP stuff is relative to derived works. It's undefined under current case law and precednt relative to the GPL, but these big companies are taking no chances....

I wasn't trying to imply that you hadn't reported them well.

It's just that I was born with a highly developed case of Altzheimers, and I have trouble keeping details around in my head for more than about five minutes.

I'm half serious, btw. It's not that I don't have a good memory, but I tend to remember patterns and how things work, and I'm _really_ bad at keeping track of details. This is why I absolutely depend on people like Alan Cox etc who maintain lists of problems, and who are good at gathering reports on what kinds of machines see it etc. I just suck at it. I really do.

Anyway, it tentatively sounds like it might have been request corruption by the new re-merge code. It fits the details, you having IDE and all. I see that you can't at least easily reproduce it in pre3 any more, but if it turns out later that you still can, please holler. Loudly.

That still leaves the SCSI corruption, which could not have been due to the request issue. What's the pattern there for people?

I care more about the 4 bytes of extra source than the 4 bytes of extra object.

I consider the 4 bytes of extra object code a compiler bug, and if we start catering for that, the bug in the compiler will never be fixed.

This is similar to how Linus forced the recognition of the "unroll-loops" bug by the gcc team.

This patch makes the same changes (dma_prog and poll) that are already made to some other OSS drivers (test12-pre3). Further it finally includes all modifications made in 2.2.18 (Alan: why do you do them line by line ?).

It implements mono output and fixes a bug in the dma logic (reset necessary because some descriptors are already prefetched and are not updated when the dma is only halted and not reset). There is still a bug in the device close handling, it gives an occasional dma overrun error.

It has been tested on by 3 people on 4 different machines with 3 different chip sets and at least 3 different codecs, so it really should work ! And it does the same things the alsa driver does.

If you start killing format conversion then >99% of the existing applications won't work anymore with usbaudio. At that point you can dump the OSS interface just as well.

And before killing format conversion you should kill the mmap stunt, because the format conversion complexity (~25 LOC) is by far dwarfed by the mmap emulation stuff.

The underlying question is:

• do we want an usb audio driver that supports the OSS interface and with which most existing applications work
• or do we want a simple driver with its own non-OSS interface.

Anything in between is IMO silly. Killing the format conversion drops the advantage of running many existing applications but don't bring you much closer to the goal of simplicity.

Those applications already have to deal with the fact some devices only support 48KHz 16bit stereo audio. I run a full desktop environment on such hardware without problems.

What format is it that causes the problems, the only badly supported key format right know I know of is 16bit bigendian. That needs some small esd patches.

My apologies. There was a "oops in SoftwareRAID autodetect" in test10 and test11 that was fixed in test12pre3, and I just assumed that your's was the same, and didn't look at it properly.

On looking again, your problem is definately different and quite weird.

I am working on enabling Linux console for Local languages. As the current PSF format doesn't support variable width fonts , I have made a patch in the console driver so that it will load a user defined multi-glyph mapping table so that multiple glyphs can be displayed for a single character code. All editing operations will also be taken care of.

Further, for Indian languages, there are various consonant/vowel modifiers which result in complex character clusters. So I have extended the patch to load user defined context sensitive parse rules for glyphs / character codes as well. Again, all editing operations will behave according to the parse rule specifications.

Even though the patch has been developed keeping Indian languages in mind, I feel it will be applicable to many other languages (for eg. Chinese) which require wider fonts on console or user defined parsing at I/O level.

Currently I have developed the patch for Kernel versions 2.2.14 and and am in the process of making it for 2.2.16 and 2.2.17. I request people to try out this patch and give comments and suggestions to me.

Those who want to try out this patch can send mail to me in the address rathee@lantana.iitm.ernet.in or to indlinux-iitm@lantana.iitm.ernet.in

The package , containing the patch , some documentation ,utilities and sample files will come around 100 KB.

here is my latest attempt to find a way to toggle A20M# that genuinely works on all machines -- including Olivettis, IBM Aptivas, bizarre notebooks, yadda yadda.

The bizarre notebooks with broken SMM code are the ones I really worry most about... there may very well be NO WAY to support them that actually works on all machines, because you don't get any kind of feedback that they are broken.

If you have had A20M# problems with any kernel -- recent or not -- *please* try this patch, against 2.4.0-test12-pre5

The protected-mode switch in INT 15 is probably the least tested BIOS function ever. I wouldn't trust it, and relying on it will put further burden on embedded Linux developers, many of whom don't even have a BIOS. It is 'least tested' because there is no way provided to get back to real-mode. This implies that somebody probably 'tested' it once, verified that some simple 32-bit function executed for a few microseconds, then declared; "It works!".

Many new chip-sets snoop for the sequence:

Write 0xd1 to port 0x64
Write 0xN1 to port 0x60

... Where 'N' are any bits and the LSB enables A<20> propagation.

The writes have to be in sequence, therefore, one must read 0x60 first, OR in bit 0. Write 0xD1 to 0x64, then write the new enable- value to port 0x60.

It takes about 700 to 1500 microseconds for a real keyboard controller to enable the A<20> propagation bit. It takes only a few hundred nanoseconds for the virtual sequence, above, to do the same thing.

On all machines I have looked at, including several lap-tops, the 'fast' A<20> enable port is R/W. This means that you don't have to crash the machine by setting some secret reserved bit. Just read first, OR in your A<20> bit, then write.

You can experiment by booting DOS (or free-DOS), and play using DEBUG. Setting A<20> while in real-mode DOS won't hurt anything. You can even check for wrap beyond FFFF:0000 from DEBUG to see if the bit is enabled.

I suggest that a "universal" sequence is the D1/N1 sequence shown above (this will work with real keyboard controllers), you don't have to wait for completion of the last command as long as you don't have more than two commands in sequence. This is because the controller doesn't know if you ever read the status, and it will execute the next command, if one exists, as soon as it writes the completion status from the previous.

The next step of the "universal" sequence, if the previous doesn't work, would be to enable the fast A<20> bit (only) in port 0x92.

I bet I know what's up.

Want to bet $5 USD that suspend/resume saves the keyboard A20 state, but does NOT save the fast-A20 gate information?

So anything that enables A20 with only the fast A20 gate will find that A20 is disabled again on resume.

Which would make Linux _really_ unhappy, needless to say. Instant death in the form of a triple fault (all of the Linux kernel code is in the 1-2MB area, which would be invisible), resulting in an instant reboot.

Peter, we definitely need to do the keyboard A20, even if fast-A20 works fine.

Yup. It's a BIOS bug, oh what a shocker... (that never happens, right)?

I might hack on using INT 15h to do the jump to protected mode, as ugly as it is, but I won't have time before my trip. It would require quite a bit of restructuring in setup.S, and would probably break LOADLIN.

Right now this is my interim patch (to clean test11). The thing to note is that I decreased the keyboard controller timeout by a factor of about 167, while making the "delay" a bit longer.

Now, if you don't have a keyboard controller, the bootup delay should be on the order of 1.2 seconds or so (calling empty_8042 three times, each around 0.4 seconds to time out). Which is acceptable. Especially as the non-keyboard-controller machines that don't even emulate one are quite rare. And it's still long enough that if the keyboard controller hasn't emptied in 0.4 seconds, something else is badly wrong.

The non-keyboard-controller timeout used to be around three minutes before. Which _definitely_ is excessive. Most people would assume that the machine had hung.

Okay, here is yet another A20 patch (against test12-pre6) this time for people to try out. This patch uses the following algorithm for enabling A20:

1. Try the BIOS call. If it works, we're cool.
2. Try the KBC (using Linus' lowered timeouts.)
3. If the KBC doesn't work, or is very slow, flip port 92.

After 3 it sits into the same infinite loop waiting for A20 to become enabled (necessary on for example some Toshiba notebooks which have an extremely slow response to A20.)

The main differences between this patch and test12-pre6:

• Trying the BIOS first of all. This should reduce the risk of the BIOS getting confused while doing a suspend. This also gives even less of an excuse for any nonstandard arrangement -- if you didn't implement the standard KBC *and* you didn't provide the BIOS call, you have a seriously broken piece of hardware.
• If the KBC responds quickly enough (within about 10000 cycles), we don't ever touch the fast A20 gate. This is a difference from previous code, where the fast A20 gate was toggled immediately after the KBC, even if the KBC responded instantly.
• I had to move the A20 code somewhat earlier in setup.S in order for the BIOS to still be available.

Please try it out and let me know as soon as possible...

The cyrixIII chips by via have the centaur vendor id which causes the identify_cpu call in arch/i386/kernel/setup.c to fail. It is probably reasonable for it to have the centaur id as via owns centaur as well. I just replaced the centaur_model call with the cyrix_model one, but I know that I am using a cyrix chip.

A test probably needs to be added in the centaur_model section to test for the cyrixIII in disguise.

The error is a general protection fault.

For the kernel stuff there is a project to put documentation about functions and what they do inline into the kernel. Its slow progress. Trying to do anything formal and structured isnt going to be productive until the documentation is much much more complete

For syscalls Andries Brouwer maintains a man page collection (and writes many of them). He takes submissions.

in case he is curious where to find it:

http://www.moses.uklinux.net/patches/lki.html

(or .sgml for master source).

Interestingly, the main problem with LKI turned out to be _not_ the issue of keeping it uptodate but filling in the missing bits, most notably buffer cache and page cache. By now I more or less actually understand the Linux buffer cache (only after diligent comparison with UW7, AIX, OSR5 and many other commercial UNIX implementations whose source code is available) but still not the page cache (even after reading everything about it that I could find, including recent Understanding Linux Kernel book by Bovet which I just finished reading). E.g. it is not even obvious to me that things will get any worse if one throws away the entire readahead logic from the page cache.

So, if someone wants to write a chapter on Linux page cache and contribute it to the LKI book (and thus become a co-author :) please feel free -- it will be a proof that someone in the world actually understands it -- at the moment I doubt that very much... Take it as a challenge :)