From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Sat, 26 Feb 94 10:13:04 EST Subject: Linux-Development Digest #500 Linux-Development Digest #500, Volume #1 Sat, 26 Feb 94 10:13:04 EST Contents: Re: ipcs utility, /proc page allocation (Frank Lofaro) Re: PLEASE use the GPL -- NOT (Matt Birkholz) Re: Specialix driver (Frank Lofaro) Floppy driver is hosed! (Frank Lofaro) Re: Specialix driver (Charles Hedrick) Re: floppy: drive 0 is write protected (Jorge Cwik) Re: accessing BIOS (David Holland) Re: Context switch for pthreads (Matthew Donadio) Re: undefined symbols in modules (John Paul Morrison) Re: Context switch for pthreads (Christopher Andrew Smith) undefined symbols in modules (Erik Troan) Re: Driver for dumb digiboard? (Rob Janssen) Re: floppy: drive 0 is write protected ad nauseum (Rob Janssen) Re: undefined symbols in modules (Rob Janssen) Re: Specialix driver (Craig Milo Rogers) ---------------------------------------------------------------------------- From: ftlofaro@unlv.edu (Frank Lofaro) Subject: Re: ipcs utility, /proc page allocation Date: Fri, 25 Feb 94 05:27:11 GMT In article <2kimjb$obb@openwx.networx.com> bonn@badger.networx.com (David Bonn) writes: >A project I've been working on needs the ipcs and ipcrm programs. It is >simple to write ipcrm using existing msgctl(), semctl(), and shmctl() calls, >but ipcs needs to peek in kernel space. > >No problem, just write a /proc/ipc entry that dumps all the relevant stuff >out. Three reboots later I had this straight. However, my approach has a >huge flaw: since we only allocate one page for the /proc/ipc info in >array.c, something with a lot of output (e.g. 128 shared memory segments) >could overrun that page and stomp whatever is beyond it. This would be >very bad. > >I see a couple of ways to deal with this: > > (1) Allocate contiguous pages, where * pagesize() is guaranteed > to be large enough to hold the maximum amount of output. This may or > may not work, I haven't looked hard enough. > > (2) Check for overrun and fail if we overrun. This is likely to be > tedious to detect. I'd rather just make sure it won't happen. > > (3) Make /proc/ipc a separate subdirectory, with file entries for each > ipc object. This is probably closest to the 'spirit' of /proc. > >What I'd like to know is if I'm missing some important alternatives; and if >someone else has already solved this problem. > >-- > > David Bonn "it's an attitude" > bonn@networx.com Or how about what /proc/kcore uses: (4) Write something like a memory device driver (/proc/kcore was /dev/core), and do not use the page given, but kmalloc your own space, or whatever. Check read_core in linux/fs/proc/array.c for how it is done. All of the /proc/files should be done this way, the auto-allocation of one page system is a bit of a kludge. ------------------------------ From: birkholz@ai.mit.edu (Matt Birkholz) Subject: Re: PLEASE use the GPL -- NOT Date: 26 Feb 94 04:15:50 From: kem@prl.ufl.edu (Kelly Murray) Newsgroups: comp.os.linux.development Date: 23 Feb 1994 23:52:20 GMT References: [...] Maybe after everyone else has debugged it, extended it, passed it around, wrote scripts for it, learned to use it, wrote HOW-TO's and documention for it, the authors might suddenly claim their original work was really very valuable, and they should get compensated for it now. Duh. Then I keep my well-debugged version under the license upon which we already agreed and ignore them. I even keep getting new versions from the net as debugging and extending continue. They can't stop me; they can't change the conditions of the agreement after the fact. Even if they could, it is tantamount to breach of contract. Considering how little the GPL constrains your work, I'm surprised to see you grasping at straws. If you don't agree with the goals of the GPL, don't use it. Is somebody holding a gun to your head? Matt Birkholz birkholz@martigny.ai.mit.edu ------------------------------ Crossposted-To: gnu.misc.discuss From: ftlofaro@unlv.edu (Frank Lofaro) Subject: Re: Specialix driver Date: Fri, 25 Feb 94 06:24:04 GMT In article <1994Feb25.010232.4865@rpp386> jfh@rpp386.cactus.org (John F. Haugh II) writes: >In article <140887@hydra.gatech.EDU> gt8134b@prism.gatech.EDU (Robert Sanders) writes: >>I'm surprised that with the recent silliness over the Shadow suite that >>you haven't heard some of the more recent interpretations. RMS and >>others maintain that any program written to use an interface which >>is solely available under the GPL is to be considered a derived work. >>For example, if the only C library were glibc, and it was under the GPL >>and not the GLPL, until someone wrote a non-GPL'ed libc, any code that >>used printf() would be a derived work. For more on this, ask about >>the gmp debacle on gnu.misc.discuss. > >It doesn't matter what announcements RMS makes. There is no legal way >for you to claim that something which contains no derived code is a >derived work. Linux is not distributed with any form of non-disclosure >so all of the interfaces are public. And I can code to a public >interface any time I want. > >>I would posit that the Linux kernel is the only available implementation >>of the Linux kernel interface. The Linux kernel is GPL'ed, therefore >>any driver written to interface with the kernel is GPL'ed. Russ's >>assertion is correct in the eyes of the FSF. > >A public interface is never subject to license restrictions. IBM has >tried this position and lost. Consider the System/370 plug compatible >computer systems. IBM tried to control the interface, and lost. I >suspect that the FSF would lose as well. If they didn't lose, I'd suggest >any company being affected file a restraint of trade suit. > >>Of course, you're not even arguing that far. You say that even .o >>that are only intended to link into a GPL'ed program need not be GPL'ed. > >Correct. I can write anything I like to any public interface I like. If >I don't want to distribute that thing under the terms of the GPL all I >have to do is avoid contaminating my code with something which is under >the terms of the GPL. And public interfaces aren't subject to licensing >restrictions. >-- >John F. Haugh II [ NRA-ILA ] [ Kill Barney ] !'s: ...!cs.utexas.edu!rpp386!jfh >Ma Bell: (512) 251-2151 [GOP][DoF #17][PADI][ENTJ] @'s: jfh@rpp386.cactus.org > There are three documents that run my life: The King James Bible, the United > States Constitution, and the UNIX System V Release 4 Programmer's Reference. Well said. I REALLY DON'T want to see the FSF using the overly broad interpretation of "derived work". It could come back to haunt them by setting a precedent; one day in fact impeding free software that interfaces to or runs on or with commerical software. Something is only a "derived work" if it is a work derived from the program it is supposedly derived from. Being made to _work with_ does not mean _derived from_. ------------------------------ From: ftlofaro@unlv.edu (Frank Lofaro) Subject: Floppy driver is hosed! Date: Fri, 25 Feb 94 05:59:03 GMT The floppy driver is hosed. In the process of implementing raw devices on my system (they still need a tad of work done), I noticed a really OBNOXIOUS problem in the floppy driver. It only works with a blocksize of 1024! (i.e 2 sectors). If I use more, it only reads/writes 2 sectors out of 8 (1K out of 4K), leaving whatever junk was there in the remaining 3k of the buffer or the disk. If I use 512 bytes (1 sector), it seems to work for all sectors but the last on a track, but things still may be getting trashed. Here is the kicker! If I try to write the last sector on a track, if I am LUCKY all I get is an error saying the FDC reported error status 0x44 0x80 (cylinder overrun, i.e. sector number too high). If I am not lucky (i.e. 90% of the time), the system will immediately REBOOT! (no panic, kernel messages or nothing, just as if I hit the reset button). I had to use a blocksize of 1024 to get it to work. It indicates the floppy driver needs work, especially if the kernel is to support multiple blocksizes well, as is planned. P.S. The floppy problem is why swapon /dev/fd0 does not work: 121: whitney: 21:54:02: /usr/users/ftlofaro: # swapon /dev/fd0 Unable to find swap-space signature swapon: /dev/fd0: Invalid argument 122: whitney: 21:54:13: /usr/users/ftlofaro: # swapon /dev/fd0H1440 Unable to find swap-space signature swapon: /dev/fd0H1440: Invalid argument Swapping to a device tries to do 4K I/O, but only 1K is transferred; the rest of the buffer or the disk area being accessed is left uninitialized, thus containing whatever junk was there before, Thus swapping can not find the signature (and if it could, things would get VERY hosed when swapping actually occured). There is a realted thread about the IN2000 SCSI adapter code, which hoses up swapping, again due to a blocksize limitation. P.P.S. Swapping to a floppy could be useful under some circumstances. Like trying to install to a 4M machine using for example UMSDOS filesystems. Systems with 4M need to be able to swap to install, and you need to have an fs (thus need to have already installed - chicken and egg problem) before you can swap to a file, and if you don't want to mess with partitions, you could swap to the b: drive instead. A bit slow but probably tolerable (Heck I swapped to a file on an ext2 floppy as a test - that works, since it is a normal 1K fs access) and it is slow, but I can deal with it. ------------------------------ From: hedrick@geneva.rutgers.edu (Charles Hedrick) Subject: Re: Specialix driver Date: 26 Feb 94 02:46:13 GMT dholland@husc7.harvard.edu (David Holland) writes: >All right. The Linux kernel is the only available implementation that >will run Linux binaries. Therefore Linux binaries have been created to >interface with the Linux kernel. The Linux kernel is GPL'd. Therefore, >everything which has ever been compiled to run under Linux is >automatically GPL'd. Even if this weren't an absurd reading of the GPL, the COPYING file distributed with the kernel explicitly says that no constraints are placed on applications that simply use system calls. ------------------------------ From: jorge@laser.satlink.net (Jorge Cwik) Subject: Re: floppy: drive 0 is write protected Date: Fri, 25 Feb 94 19:05:11 -0400 niemidc@oasis.gtegsc.com (David C. Niemi) writes: > If anyone knows how to detect either floppy changes (without repeated > polling of the drive) or write protected floppies (without actually > writing to the disk), please let me know. I know there are hardware > signals from the drive that would remedy both of these problems; but > as far as I can tell these are not directly accessible via the FDC. The FDC "Sense Drive Status" command (0x04), returns the WP signal among others things, and it is a totally passive command. The "Change line" signal is available in the "Digital Input Register" ($3F7/$377). The FDC does generates an interrupt when the disk is changed, actually a couple, one when removing a disk and a second one when inserting it. Jorge ------------------------------ Subject: Re: accessing BIOS From: dholland@husc7.harvard.edu (David Holland) Date: 26 Feb 94 02:00:10 rob@pe1chl.ampr.org's message of Thu, 24 Feb 1994 22:38:33 GMT said: > You should certainly look at Linux for protected mode programming. > However, Linux does not switch back to real mode by itself. > (it *is* possible to use V86 mode in a task running under Linux, > the DOS emulator uses it) And this is a good reason to be able to have microkernel-style device drivers. You can write one that runs in V86 mode and uses the BIOS to talk to weird hardware. -- - David A. Holland | Nobody ever went broke underestimating dholland@husc.harvard.edu | the intelligence of the American public. ------------------------------ From: donadio@mxd120.rh.psu.edu (Matthew Donadio) Subject: Re: Context switch for pthreads Date: 25 Feb 1994 22:50:19 GMT Christopher Andrew Smith (z1g192@rick.cs.ubc.ca) wrote: : As one of my currrent projects, I am attempting to port a package called : pthreads ( for preemptive threads ) to Linux. Most of the code should be : relatively straightforward to port, since it is written in Ansi C, but You shouldn't have to do any porting. The file sipb.mit.edu:/pub/pthreads/pthreads-1.??.tar.gz has a linux port the should work with pl15. I haven't had time to test it thouroughly, but all the built in tests seemed to work. : All threads are contained within one UNIX process which links in the : pthreads library, so they share the same process space. : A thread roughly corresponds to a procedure. I like baby-processes. From the LynxOS Real-Time Programming Seminar notes: " Threads don't have a mother! Or any siblings. Or any children. Sad, but true. UNIX processes all have a semantic weight - each process has a parent process, it may have sibling processes (who invariable squabble) and can even fork() if it wants children. Threads do not have a semantic weight associated with them. All the threads within a process are completely equal - no matter which thread created which thread. True democrats!" Does anyone know where to find man pages/docs for pthreads? The only ones I have access to are 200 miles away right now. What would be really nice if someone would start work on a kernel scheduler that is pthread compatible. I would, but kernel work is not my thing... Maybe this summer if I don't get a track bike. -- Beaker aka Matt Donadio | Life is short, --- __ o __~o __ o donadio@mxd120.rh.psu.edu | ride like ---- _`\<, _`\<, _`\<, --- Penn State Cycling ---| the wind. --- ( )/( ) ( )/( ) ( )/( ) ------------------------------ From: jmorriso@bogomips.ee.ubc.ca (John Paul Morrison) Subject: Re: undefined symbols in modules Date: Sat, 26 Feb 1994 08:50:10 GMT In article <2klvfa$gtv@bigblue.oit.unc.edu>, Erik Troan wrote: [ modules stuff ] >Everything was going dandy until I tried to use call get_chrfops. When >I try to load the module, I get the message "_get_chrfops undefined", >though it appears in /usr/src/Linux/zSystem.map. > add _get_chrfops to kernel/ksyms.S >Erik -- ========================================================================== BogoMIPS Research Labs -- bogosity research & simulation -- VE7JPM -- jmorriso@bogomips.ee.ubc.ca jmorriso@rflab.ee.ubc.ca ========================================================================== ------------------------------ From: z1g192@rick.cs.ubc.ca (Christopher Andrew Smith) Subject: Re: Context switch for pthreads Date: 25 Feb 1994 16:11:53 -0800 In article <2klvbb$5b9@genesis.ait.psu.edu> donadio@mxd120.rh.psu.edu (Matthew Donadio) writes: >Christopher Andrew Smith (z1g192@rick.cs.ubc.ca) wrote: >: As one of my currrent projects, I am attempting to port a package called >: pthreads ( for preemptive threads ) to Linux. Most of the code should be >: relatively straightforward to port, since it is written in Ansi C, but > >You shouldn't have to do any porting. The file > sipb.mit.edu:/pub/pthreads/pthreads-1.??.tar.gz >has a linux port the should work with pl15. I haven't had time to test >it thouroughly, but all the built in tests seemed to work. > Yeah ... I've seen the package. My interest is purely academic, so I'm attempting to port it to learn about OS's and kernels. Actually, the pthreads package we use is different from the one at MIT. Maybe not in functionality, but the source code is definitely different. The package I want to port was developed at University of British Columbia. >: All threads are contained within one UNIX process which links in the >: pthreads library, so they share the same process space. > >: A thread roughly corresponds to a procedure. > >I like baby-processes. I like that term too! :-) [stuff deleted] >really nice if someone would start work on a kernel scheduler that is >pthread compatible. I would, but kernel work is not my thing... >Maybe this summer if I don't get a track bike. > This is what my ultimate goal is. (IE to make threads part of my Linux kernel) This will probably take me quite a while, since I am just now learning about operating systems (IE scheduling, memory management, process ADT's, critical sections, etc ) and UNIX (Linux). >-- >Beaker aka Matt Donadio | Life is short, --- __ o __~o __ o >donadio@mxd120.rh.psu.edu | ride like ---- _`\<, _`\<, _`\<, >--- Penn State Cycling ---| the wind. --- ( )/( ) ( )/( ) ( )/( ) - -- ======================================================================== |Christopher Smith | With a rubber duck, one's never alone. | |aka z1g192@ugrad.cs.ubc.ca |-- "The Hitchhiker's Guide to the Galaxy"| ======================================================================== ------------------------------ From: ewt@sunSITE.unc.edu (Erik Troan) Subject: undefined symbols in modules Date: 25 Feb 1994 22:52:26 GMT Since my girlfriend left me for a while this afternoon, I started to play with module development, using modutils-0.99.15.tgz as uploaded to sunsite. Everything was going dandy until I tried to use call get_chrfops. When I try to load the module, I get the message "_get_chrfops undefined", though it appears in /usr/src/Linux/zSystem.map. ie: [3] insmod drv_load.o _get_chrfops undefined [4] grep chrfops /usr/src/linux/zSystem.map 0011e000 T _get_chrfops I can call register_chrdev(), schedule(), access current, etc. with no problems. I tried relinking my kernel to no avail. Any clues? Erik -- ======================================================================== "Could I bend yer ear fer a tick?" ewt@sunsite.unc.edu = Erik Troan sasewt@unx.sas.com - Strictly Ballroom ------------------------------ From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: Driver for dumb digiboard? Date: Sat, 26 Feb 1994 10:31:33 GMT Reply-To: pe1chl@rabo.nl In jjw@seastar.org (John Welch) writes: > We are considering switching over from SCO Xenix to Linux, but >have run into a snarl - it doesn't appear that Linux supports the old, >dumb 8-port Digiboard that we currently use. > Have I just missed it in serial.c? Or does anybody know where >such a beastie might be obtained? ADVthanksANCE. I don't know this specific board, but when it is a dumb board it should be easy to support it by simply setting the I/O port addresses and interrupt numbers. This can be done in serial.c, but it is more convenient to run the program "setserial" at boottime (from /etc/rc), like this: setserial /dev/ttyS2 port 0x220 irq 15 autoconfig setserial /dev/ttyS3 port 0x228 irq 15 autoconfig setserial /dev/ttyS4 port 0x3e8 irq 15 '^fourport' autoconfig setserial /dev/ttyS5 port 0x2e8 irq 15 '^fourport' autoconfig setserial /dev/ttyS6 port 0x3e0 irq 15 '^fourport' autoconfig setserial /dev/ttyS7 port 0x2e0 irq 15 '^fourport' autoconfig setserial -bg /dev/ttyS* Note that some ports are configured as 'AST fourport' in serial.c, and this flag must be cleared or there will be problems. Note do developers (Linus, Ted): now that the automatic configuration has been dropped, why don't we drop out all that specific info from the rs_table? It is kind of inconvenient that one has to clear the 'fourport' flag for ttys in the range ttyS4..ttyS11. It seems more logical for me that the fourport owners would explicitly SET this flag. I think it would be best to set all entries in the table above the first four to "{ BASE_BAUD, 0x000, 0, 0 },", and let the setserial program setup the values appropriate for the system... Rob -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | ========================================================================= ------------------------------ Crossposted-To: comp.os.linux.help From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: floppy: drive 0 is write protected ad nauseum Date: Sat, 26 Feb 1994 10:40:57 GMT Reply-To: pe1chl@rabo.nl In <2kjmq9$2au@wsdnws.cfi.waseda.ac.jp> 63912i@cfi.waseda.ac.jp ("Alexander During") writes: >The thing is, Linux can check for disk changes. So you know when a new disk >is put in. I would mount have mark this disk for non write cache initially. >Then comes the first write, which thus goes straight onto the disk. If >this works, the disk can safely be cached, which should be the next thing >the VFS establishes. >If the write fails, just tell the user program. That should be possible, and a good solution I think. Most problems with removable media will appear at the first write. (or at the first read for some others) >BTW, there is something that really bugs me every time under X. If I try >to clean a disk with mdel and it happens to be write protected, mdel ends >happily and all the 'write protected' messages go to the console, which I >can't see (some thing with my site administrator, but sometimes we have >problems talking about that stuff - he is not so good in reading English >manuals and I have trouble explaining them in Japanese :-)). Same thing >with any writes. Result: you write, everything seems OK and later you >wonder where all your data is. An easy way to see kernel messages in X is to run a: tail -f /proc/kmsg in some window. of course you need to run it as root. (no need to tell me there are problems with this, and other methods to do it!) >I think this is really a system design problem. As far as I can see, there >is no way telling an application that it's cached write has failed. How >about sending a SIGLOST if trouble with a file system is detected long >after a write? I mean, it's not very compliant and all, but according to >my linux/signal.h, this signal is not used yet and it would be a good >thing to know something. >Other thing, if I flush() a file, can't this be used to also flush the >cache? This is supposed to be done using fsync() Rob -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | ========================================================================= ------------------------------ From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: undefined symbols in modules Date: Sat, 26 Feb 1994 10:55:01 GMT Reply-To: pe1chl@rabo.nl In <2klvfa$gtv@bigblue.oit.unc.edu> ewt@sunSITE.unc.edu (Erik Troan) writes: >Since my girlfriend left me for a while this afternoon, I started to play >with module development, using modutils-0.99.15.tgz as uploaded >to sunsite. >Everything was going dandy until I tried to use call get_chrfops. When >I try to load the module, I get the message "_get_chrfops undefined", >though it appears in /usr/src/Linux/zSystem.map. >ie: >[3] insmod drv_load.o >_get_chrfops undefined >[4] grep chrfops /usr/src/linux/zSystem.map >0011e000 T _get_chrfops >I can call register_chrdev(), schedule(), access current, etc. with >no problems. I tried relinking my kernel to no avail. >Any clues? >Erik I think you should put the symbol in kernel/ksyms.S, the list of symbols exported to modules. Rob -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | ========================================================================= ------------------------------ From: rogers@drax.isi.edu (Craig Milo Rogers) Subject: Re: Specialix driver Date: 25 Feb 1994 13:20:38 -0800 First, the CYA announcement: I am not a lawyer. The contents of this message do not represent legal advise. In article <1994Feb22.173853.19781@super.org> becker@super.org (Donald J. Becker) writes: >A Linux device driver, on the other hand, is an integral and >inseparable(1) part of the Linux kernel. By the terms of the GPL it must be >released in source form. I apologize for disagreeing with an important Linux device driver writer, but this statement is too general. First the good news, which some will consider the bad news: :-) Organize your device driver into two sections. The "pure" part should: 1) contain the code you want to keep secret, and 2) should work (compile, execute) for several different operating systems, without ifdefs of other operating-specific checks. The other, "impure", part, must contain all global names, subroutine calls, etc. which make up the interface for a particular operating system. To protect yourself, you ought to have "impure" parts actually working for more than one operating system. You might consider distributing versions for freeBDS, netBDS, SCO, Netware, BSD386, ... Under the terms of the GPL (version 2 assumed in this discussion), you are free to distribute your "pure" portion in ways that do not comply with the GPL, such as an object-only distribution. The GPL does not apply to the "pure" code, and the GPL even has the grace to explicitly acknowledge this. It is also important to remember that the GPL does not prevent you from modifying GPLed stuff into non-GPL-conformable stuff (in source or object format), so long as you do not distribute or publish the modified works (Section 2b). Under the terms of the GPL (assuming that these hold in court), the Linux-impure part of your driver *must* be distributed in a GPL-compliant fashion. Distributing it as source code is, one hopes, safe. Distributing it as object code might be open to question: it might be considered incomplete without the "pure" code. One way around this is to use the same "impure" code with several different "pure" parts, and release one of these "pure" parts in source form. A crippled copy of your "pure" secret code may be open to attack, so it would be better to have a verifiably independent non-secret "pure" part available. Now for the bad news (some people's good news :-): It would be inadvisable to distribute your pure secret and the and Linux-impure portions linked together into a single object module or executable. Doing so would violate the GPL. Your complete driver, without source to the pure part, may not be linked as part of a publicly-distributed kernel distribution, for example. *You* may not supply your customers with a prelinked Linux kernel containing your partially-secret driver, either. >Responding to some of the other followups: 'modules', a mechanism loadable >kernel device drivers, does not change the terms of the GPL. Both the letter >and the intent of the GPL is to insure source-code-available distributions. >A loadable module is designed to work integrally and inseparably with only >the Linux kernel, and merely distributing it separately does not relieve it >of the GPL obligations. The difference in method by which a 'modules' >device driver is integrated with the remainder of the kernel (a run-time >linkage vs. a kernel-compile-time linkage) is minor and irrelevant. While I acknowledge that a "modules" mechanism doesn't change the terms of the GPL, it may nonetheless critically change how the GPL applies. Assume,as a strawman, that the runtime kernel module loader can load a secret, "pure" object file as a seperate step from loading a GPL-compliant "impure" object file. [I do not know whether the current modules package can do this, and I apologize for not researching before speculating.] Consider a package containing: 1) the Linux "impure" part, in object and source code, 2) your "pure" secret part, in object code only, 3) some independent (in the legal sense) "pure" part, in object and source code. This should, I hope, qualify as "mere aggregation" of your non-GPLed secret with a GPLed work, as allowed by Section 2 of GPL2. [However, as I said, I am not a lawyer, and I offer a layman's opinion, not a legal one. There may be circumstances in which the package of three files might be considered "whole" instead of an "aggregation".] Such a distribution would be a lot more convenient to use than one that requires each customer to static link their own kernel. Thus, the introduction of loadable modules effectively increases the potential to create and distribute non-GPL-conformant Linux device drivers, as part of a commercial Linux distribution or in a package delivered to a customer of the secret holder. There are still a few details that could derail such a project, though. Thank you for your atention. Craig Milo Rogers ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development) via: Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Development Digest ******************************