Subject: Linux-Development Digest #506
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Sun, 27 Feb 94 20:13:05 EST

Linux-Development Digest #506, Volume #1         Sun, 27 Feb 94 20:13:05 EST

Contents:
  Re: effectiveness of cache ram? (Eric J. Schwertfeger)
  Connecting IPX to IP (Edward van der Jagt)
  Re: undefined symbols in modules (Frank Lofaro)
  Re: Specialix driver (Frank Lofaro)
  Re: BSD file system for linux ? (Matthias Urlichs)
  pl15h I/O-prob sdb1 "mount -t msdos -o ..." (Karl Eichwalder)
  Re: Specialix driver (Wayne Schlitt)
  Re: effectiveness of cache ram? (Steffen Neumann)
  Re: PLEASE use the GPL  -- NOT (Kelly Murray)
  Re: PLEASE use the GPL  -- NOT (Craig Burley)
  Multiple Inheritance with G++ (Jeffrey Stockett)
  SOLUTION: floppy: drive 0 is write protected (Johannes Stille)
  Re: Specialix driver (Kai Henningsen)
  Re: Specialix driver (Kai Henningsen)
  Re: [Q] Is there Shared Library for GNU Readline ? (Thomas Pfau)

----------------------------------------------------------------------------

From: [email-masked] (Eric J. Schwertfeger)
Subject: Re: effectiveness of cache ram?
Date: Sat, 26 Feb 94 17:46:09 GMT

In article <[email-masked]> [email-masked] (William Henning) writes:
>In article <[email-masked]> [email-masked] (Tom Briggs) writes:
>>I believe, from my experience, that if you are talking 386, you want
>>as much cache as you can get.  If you are talking 486, RAM cache is not
>>really all that extravagent.   I have seen 486/33 DX with 64k, 128, and 256k
>>and all of them performed the same. 
>
>The above is absolutely true for trivial benchmarks such as SI, Landmark,
>etc., that fit into the 8k on-chip cache. The above is FALSE for large
>programs.

Agreed.

>Test setup:
>
>VLB Intel 486DX2-66, 256k cache, 16Mb ram, WD250 mb HD, OS/2 v2.1
>
>Test:
>
>Compilation/linking of ~100k of C source code with icc.
>
>With internal/external caches enabled: about 2 minutes
>With internal cache enabled, external disabled: about 6 minutes
>With internal and external caches disabled: about 8 minutes
>With internal cache disabled, external enabled: about 3 minutes
>
>(Numbers from memory)
>
>>So, no, I would say that more memory is a better thing than more cache.
>
>More memory is ALLWAYS a good thing. If you swap a lot, cache efficiency
>gets lost in the time spent swapping. If you are not swapping, the more
>cache the better.

Also agreed.  I find that the external cache did make little
difference when I was compiling the Linux kernel with 4 Meg of ram,
but at 8 or 16Meg, it makes a profound difference (though not as much
as posted above).  for the latter, disabling the external cache cost
about 5 minutes compile time, but only 3 minutes for the former.  I
never did figure that one out :-)

-- 
Eric J. Schwertfeger, [email-masked]

------------------------------

From: [email-masked] (Edward van der Jagt)
Subject: Connecting IPX to IP
Date: Sun, 27 Feb 1994 15:07:24 GMT

I've recently bought a diskless workstation/terminal, which has been
setup for use with a Novell network (with a boot-prom). It is not possible
to attach any drives to the terminal. The boot-prom cannot be replaced
either, because no new ones are made anymore (outdated).
I also have a PC running Linux (a Unix-clone) with tcp/ip and nfs support.

What I want is the following:
        - connect the terminal by ethernet to my Unix-machine (server)
        - let the terminal boot DOS from an image obtained from the
        server (just as it would in a Novell-network)
        - let the terminal use programs from drives on the server
        (DOS-programs ofcourse)

It is not necessary to have any security-checks, I just want to run
programs on the terminal, coming from the (UNIX-)server.

What I am now looking for, is any information or sources of programs,
possibly contributing to the solution of the problem stated above.
And, particularly, specifications of the IPX/IP/NetBIOS protocols.

                                Edward
                                [email-masked]

------------------------------

From: [email-masked] (Frank Lofaro)
Subject: Re: undefined symbols in modules
Date: Sat, 26 Feb 94 22:24:16 GMT

In article <[email-masked]> [email-masked] writes:
>In <[email-masked]> [email-masked] (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.
>

How about someone changing the modules code to not depend on a static 
ksyms list? If I while having a system running, want to use a module to 
load code that depends on functions or variables not provided for in ksyms, 
I have to recompile after adding it to ksyms and reboot before I can use 
the module. This defeats the purpose of loadable modules.

------------------------------

Crossposted-To: gnu.misc.discuss
From: [email-masked] (Frank Lofaro)
Subject: Re: Specialix driver
Date: Sat, 26 Feb 94 22:29:43 GMT

In article <[email-masked]> Chris Royle <[email-masked]> writes:
>
>I'm disgusted by all this prevaricating that's going on. I suggest Specialix
>get on and do it.
>

A lot of the discussion has veered from the facts of the case.

IN SHORT: WHAT SPECIALIX WANTS TO DO IS LEGAL.

It is only trivially different than they making GPL'd patches to the kernel, 
and having you do cat /some/proprientary/file > /dev/device to load the 
device. Would that file get infected by the GPL? Surely not. What they were 
suggesting was not much different. People should READ the original post.

------------------------------

From: [email-masked] (Matthias Urlichs)
Subject: Re: BSD file system for linux ?
Date: 27 Feb 1994 11:59:01 +0100

In comp.os.linux.development, article <[email-masked]>,
  [email-masked] (Robert Sanders) writes:
> 
> Maybe once 4.4-Lite comes out someone will get bored and port FFS
> and the log-based filesystem to Linux.  Matthias Urlichs has already
> ported the BSD networking code, so it shouldn't be *that* difficult.
> 
Unfortunately, not true.

The networking code is reasonably separate from the rest of the kernel.
File system stuff, on the other hand, depends on quite a few kernel
internals, among them organization of inode/vnode/struct file/superblock/et
al, which are somewhat different between Linux and BSD. "Get it to compile
and add a few bytes of glue code", which is essentially what I did for the
networking code (OK, so the interrupt handling had to be tweaked), won't be
enough if you want to port the FFS.

-- 
Forwarded for your consideration - you hold the bag for a while
                                -- Glossary of important business terms
-- 
Matthias Urlichs        \ XLink-POP Nürnberg  | EMail: [email-masked]
Schleiermacherstraße 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 Nürnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

------------------------------

From: [email-masked] (Karl Eichwalder)
Subject: pl15h I/O-prob sdb1 "mount -t msdos -o ..."
Date: Sun, 27 Feb 1994 10:27:59 GMT

Configuration:

386DX33, Adaptec 1542B, Quantum LPS 240, Syquest 44MB, NE2000 clone, ET4000.

pl15h, libc.so.4.4.4, ld.so.1.4.

mount --version: Linux bootutils 0.99.14 (=linux-util-1.4,tar.gz).

Until yesterday special mount options work w/o any prob, e.g.:

# mount -t msdos -o conv=auto,uid=405,gid=50,umask=027 /dev/sdb1 /mnt/sq

But now user 405 couldn't copy files from the Syquest medium (for root the
same).

        $ cp -a /mnt/sq/a1 ~

will produce somthing like:

        $ ll ~/a1
-rwxr-x---   1 karl     group         416 Feb 19 10:00 00index.txt*
-rwxr-x---   1 karl     group         418 Feb 19 08:30 devs.tgz*
-rwxr-x---   1 karl     group        3623 Feb  5 07:48 diska1*
-rwxr-x---   1 karl     group         196 Feb 15 21:04 etc.tgz*
-rwxr-x---   1 karl     group         397 Feb 16 23:08 hdsetup.tgz*
-rwxr-x---   1 karl     group        3012 Feb  5 07:48 idekern.log*
-rwxr-x---   1 karl     group         662 Feb  5 07:48 idekern.tgz*
-rwxr-x---   1 karl     group         182 Feb  5 07:48 lilo.tgz*
-rwxr-x---   1 karl     group        2789 Feb  5 07:48 maketag*
-rwxr-x---   1 karl     group        3861 Feb  5 07:48 scsikern.log*
-rwxr-x---   1 karl     group         142 Feb  5 07:49 scsikern.tgz*
-rwxr-x---   1 karl     group         102 Feb 15 01:38 sysvinit.tgz*
-rwxr-x---   1 karl     group        4036 Feb  5 07:49 tagfile*
-rwxr-x---   1 karl     group        4036 Feb  5 07:49 tagfile.org*
-rwxr-x---   1 karl     group         876 Feb  5 07:49 tagfile.pat*

The contents of the files are still missing.

BTW `mount mount -t msdos /dev/sdb1 /mnt/sq' works alright.

Seems the same w/ mtools:

pertron:~# mcopy /mnt/sq/a1/lilo.tgz a:
Copying LILO.TGZ
putcluster: fread: No such file or directory
mwrite: Disk full                               #### No !!! ->|
pertron:~# mdir                                               |
 Volume in drive A has no label                               |
 Directory for A:/

00INDEX  TXT         104   11-03-93   9:02a
DISKA10              264   10-22-93   3:57a
GCC245   TGZ      533570   11-02-93  10:45p
GXX245   TGZ      787416   10-22-93   3:58a
RAWRITE  EXE       13052   12-15-93  10:50a                   |
ETC      TGZ       55475    2-15-94   8:04p                   |
       6 File(s)      66048 bytes free <---------------<--<---|
pertron:~# ll /mnt/sq/a1/lilo.tgz 
-rwxr-x---   1 karl     group       55420 Feb  5 07:48 /mnt/sq/a1/lilo.tgz*
-- 
                        | Internet  : [email-masked]
                        |           : [email-masked]
Karl Eichwalder         | Fido      : 2:2437/210.55

------------------------------

From: [email-masked] (Wayne Schlitt)
Subject: Re: Specialix driver
Date: Sun, 27 Feb 1994 18:41:12 GMT
Reply-To: [email-masked]

In article <[email-masked]> [email-masked] (Doug DeJulio) writes:
> The FSF got mad and their lawyers contacted NeXTs lawers, or something
> like that.  In the end it was determined that since you couldn't use
> those .o files without linking them to GPLed sources, they were
> obviously a derivative work and so they fell under the GPL as well.
> 
> The result: NeXT was forced to release their Objective-C compiler
> under the GPL.  That's why GCC includes an Objective-C compiler today.

I believe that this is a distortion.  FSF did contact NeXT, but did
not _force_ them to release their work.  The did _convince_ them that
they should, but link kit technique does seem to be a legal way of
distributing stuff.  FSF has _never_ sued anyone.  When they find out
about something that is questionable, the _do_ contact the people
involved for clarifications and such.  To me, this seems like a
reasonable thing to do.

-wayne

-- 
The Fundamental Problem with USENET is that you have at least a couple
of hours, if not a day or so to think up that witty, absolutely
devastating retort...  The other Fundamental Problem is people don't
even take a couple of minutes to think before they hit that send key...

------------------------------

From: [email-masked] (Steffen Neumann)
Subject: Re: effectiveness of cache ram?
Date: Sun, 27 Feb 1994 18:29:45 GMT

In article <[email-masked]> [email-masked] (J Rozes) writes:

   Newsgroups: comp.os.linux.development
   Path: news.uni-bielefeld.de!news.dfn.de!news.coli.uni-sb.de!sbusol.rz.uni-sb.de!xlink.net!howland.reston.ans.net!noc.near.net!news.tufts.edu!jrozes
   From: [email-masked] (J Rozes)
   Sender: [email-masked] (USENET News System)
   Organization: Tufts University Computer Science Dept.
   Date: Thu, 24 Feb 1994 04:16:31 GMT
   Lines: 10

   I am looking at new system boards and have come across a few boards that
   support rather large (by pc standards) caches. I am wondering how a large
   cache (512k - 1meg) would affect linux performance. Any theories and/or
   experiences would be appreciated. Basically it boils down to this: is it
   worth it for me to sink an extra $150-200 into a big cache, or should I
   stick with 256k and spend the extra money on $150-200 of ram (don't know
   how much that buys these days)?

   thanks,
   jonathan

Well, I read some of the followups talking about what / and how cache will 
boost performance.
Of course everything depends on the board design, so I will fire up somethiung
that might be ridiculous on first sight:
get a board without cache! 
                                   ?????

(I apologize for eventually being somewhat inprecise in correct numbering...)

In the german computer journal c't 1/94 (maybe 12/93 or 2/94) there was
a nice article about the SHASTA Chipset by Headland. They showed some figures
about the waitstaites neccessary. Of course a good designed cache might 
be able to do an 2-1-1-1 if there is a cache-hit. But it can slow down
to something like 14-4-4-4 (Sorry, memory is lacking exact figures...)
if everything goes wrong.
The Shasta uses bank interleaving, like the good old NEAT boards.
That means you can decrease the waitstaites compared to the standard
system designs down to 4-2-2-2 in EVERY case.  

So due to the fact that there are more cache-misses using Linux compared
to DOG/Windos that matters even more than the top speed like 2-1-1-1.
(There were also figures given on locality of code dos/linux)

So, first I would like someone with that magazine at hand to rewrite 
this article using correct facts and 
second hear about experiences with that chipset

Steffen
 
--
Steffen Neumann                      Computer science is the dangerous try
[email-masked]    to overcome human intelligence

------------------------------

From: [email-masked] (Kelly Murray)
Subject: Re: PLEASE use the GPL  -- NOT
Date: 27 Feb 1994 20:29:34 GMT

In article <[email-masked]>, [email-masked] (Matt Birkholz) writes:
|>    From: [email-masked] (Kelly Murray)
|>    Newsgroups: comp.os.linux.development
|>    Date: 23 Feb 1994 23:52:20 GMT
|>    References: <[email-masked]> <[email-masked]>
|> 
|>    [...]
|>    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?
|> 

I agree with you!  I'm afraid you misunderstood my comment.  
The quoted material refers to NON-GPL'd licenses which include ADDITIONAL
restrictions BEYOND the GPL.  Thus as much as I believe the GPL is
misguided, it IS better than some licensing used by some people,
which is what Russ Nelson was complaining about.

If there is a Gun pointed at anyone, it is the one held by the GPL lawyers
that are trying to protect everyone by telling me I can't use their software 
in my programs. 

-- 
- Kelly Murray  ([email-masked]) <a href="http://www.prl.ufl.edu">
University of Florida Parallel Research Lab </a> 96-node KSR1, 64-node nCUBE
See <a href="file://ftp.netcom.com/pub/ncx/home.html"> NCX's home page</a>
or send mail to [email-masked] for deals on Actix S3 Video cards:
GE32+ $115, GE32iVL/2mb $219, Ultra+2mbVram $299

------------------------------

From: [email-masked] (Craig Burley)
Subject: Re: PLEASE use the GPL  -- NOT
Date: 27 Feb 94 16:28:25

In article <[email-masked]> [email-masked] (Kelly Murray) writes:

   If there is a Gun pointed at anyone, it is the one held by the GPL lawyers
   that are trying to protect everyone by telling me I can't use their software 
   in my programs. 

Fortunately, that gun is mythical, since GPL lawyers aren't telling
you you can't use their software in your programs.  In fact, GPL
supporters, and the GPL itself, actually encourage you to do so.
--

James Craig Burley, Software Craftsperson    [email-masked]
Member of the League for Programming Freedom (LPF) [email-masked]

------------------------------

From: [email-masked] (Jeffrey Stockett)
Crossposted-To: comp.os.linux.help,gnu.g++.help
Subject: Multiple Inheritance with G++
Date: 27 Feb 1994 22:32:12 GMT

Hello all,

In trying to port some code that works fine under every cfront 2.x and
3.x compiler I know of, I've run into a problem with G++.  In short,
it seems to be whacking out on multiple inheritance.  I have a class
as follows:

class stringstream : virtual public ios, public gstreambuf, public iostream
{
  ...
}

Is anyone out there using this many levels/kind of multiple inheritance with
G++?  Does G++ support it correctly?  We really want to port some of our
applications to Linux, but as we use this class stringstream in many
places, we are stuck until such time as a fix is found.

Regards,

--
************************************************************************
* Jeffrey M. Stockett     *  Tel: (512) 346-9199  Fax: (512) 346-8990  *
* Quadralay Corporation   *  FTP Address:  ftp.quadralay.com           *
* [email-masked]  *  WWW Server:   www.quadralay.com           *
************************************************************************
        "Software Development Tools That Work The Way You Do!"

------------------------------

Crossposted-To: comp.os.linux.help
From: [email-masked] (Johannes Stille)
Subject: SOLUTION: floppy: drive 0 is write protected
Date: Sun, 27 Feb 1994 16:50:30 GMT

In article <[email-masked]> [email-masked] writes:
>In article [email-masked], [email-masked] (Frank Lofaro) writes:
>...
>>Here's an idea.
>>Have the kernel not allow a filesystem to be mounted read-write if the 
>>media is write-protected. That way writes will fail with EROFS error 
>>instead of not knowing until the sync.

This is useful. Also we shouldn't allow opening the disk device
read-write when the disk is write protected.

>Unfortunately, 'tis not so easy on floppies.  People remove/insert
>floppies without the system necessarily knowing about it.  Thus a
>read-write medium may be replaced by one that is read-only; a second
>check is needed to determine whether or not the floppy is writable.

This is a problem I have no solution for yet (see below).

>The second gotcha is that it seems to be very difficult or impossible
>to detect write-protectedness other than by actually writing to the
>floppy.  If I find a way to do it, I'd be glad to implement it, but
>I'm not sure this is really possible (and it would be highly anti-
>social to go trying to write to floppies when they are mounted, even
>if it is a write of the data already there).

But in this point, I can help. The floppy controller has a "get status"
command which you can use to read the status register ST3 which in turn
contains a Write Protected bit.

>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.
>---
>David C. Niemi  [email-masked]
>------------------------------------------------------
>Now I must sit here and ponder the yonder
>Herbivores ate well 'cause their food didn't never run
>
>

I have implemented the write-protection check in the floppy_open
function. So the check is made both for just opening the device file and
for mounting. There are two problems left:

1. There is no check yet when the floppy is remounted. So you can mount
a write protected floppy read only and then remount it read-write. I'm
not sure how this is handled best. Maybe we should add a reopen pointer
to the file operations for a function that is called when the access
mode of the file is changed. This would only be used for remount, so it
is probably overkill, but IMHO it's the most clean solution. Any
comments?

2. There is no wp check at all if the floppy is changed while it is
opened/mounted. Again, I don't know what one could do in this case. In
theory, I think we should forcibly close all files open on the floppy
and unmount it, even without updating. Or would this break a
multi-volume tar? Checking for write protection is then only a minor
additional problem. Anyway, I don't know how one could do this, so I did
nothing about this problems. Any ideas are welcome.

Additionally, I'm not sure whether EACCES is the correct error to return.

Since the patches are quite short, I append them to this article. Be
careful, they aren't tested very well. Make backups of your disks before
you use them (or write-protect the disks :). If you find a bug in them,
please mail me (especially if a process hangs in the disk access (state
"D" for ps)).

        Johannes

diff -r --unified=1 linux.14v.beta4.bak/drivers/block/floppy.c linux/drivers/block/floppy.c
--- linux.14v.beta4.bak/drivers/block/floppy.c  Mon Dec 27 06:23:53 1993
+++ linux/drivers/block/floppy.c        Sun Feb 27 17:05:35 1994
@@ -138,3 +138,3 @@
 #define ST2 (reply_buffer[2])
-#define ST3 (reply_buffer[3])
+#define ST3 (reply_buffer[0]) /* same place as ST0, but from another command */
 
@@ -655,3 +655,3 @@
                                } else {
-                                       printk("unknown error. ST[0..3] are: 0x%x 0x%x 0x%x 0x%x\n", ST0, ST1, ST2, ST3);
+                                       printk("unknown error. ST[0..2] are: 0x%x 0x%x 0x%x\n", ST0, ST1, ST2);
                                }
@@ -833,2 +833,31 @@
 
+
+static int floppy_writeable(int drive)
+{
+       int r;
+
+       cli();
+       while (fdc_busy) sleep_on(&fdc_wait);
+       fdc_busy = 1;
+       sti();
+       output_byte(FD_GETSTATUS);
+       output_byte(drive);
+
+       r = result();
+       if (r != 1) {
+               printk("Floppy drive %d: couldn't get status\n", drive);
+               fdc_busy = 0;
+               wake_up(&fdc_wait);
+               return 0;
+       }
+
+       r = (ST3 & ST3_RY) && !(ST3 & ST3_FT) && !(ST3 & ST3_WP);
+
+       fdc_busy = 0;
+       wake_up(&fdc_wait);
+
+       return r;
+}
+
+
 /*
@@ -1284,2 +1319,7 @@
                check_disk_change(inode->i_rdev);
+
+       if (filp && (filp->f_mode & 2))
+               if (!floppy_writeable(drive))
+                       return -EACCES;
+
        return 0;
diff -r --unified=1 linux.14v.beta4.bak/fs/super.c linux/fs/super.c
--- linux.14v.beta4.bak/fs/super.c      Thu Jan 27 14:05:53 1994
+++ linux/fs/super.c    Sat Feb 26 22:16:02 1994
@@ -436,2 +436,3 @@
        unsigned long page = 0;
+       struct file dummy_file;
 
@@ -480,2 +481,6 @@
        }
+
+       memset(&dummy_file, 0, sizeof(dummy_file));
+       dummy_file.f_mode = (new_flags & MS_RDONLY) ? 1 : 3;
+
        fops = get_blkfops(MAJOR(dev));
@@ -482,3 +487,3 @@
        if (fops && fops->open) {
-               retval = fops->open(inode,NULL);
+               retval = fops->open(inode, &dummy_file);
                if (retval) {
@@ -500,3 +505,3 @@
        if (retval && fops && fops->release)
-               fops->release(inode,NULL);
+               fops->release(inode, &dummy_file);
        iput(inode);
diff -r --unified=1 linux.14v.beta4.bak/include/linux/fdreg.h linux/include/linux/fdreg.h
--- linux.14v.beta4.bak/include/linux/fdreg.h   Wed Dec  1 13:44:15 1993
+++ linux/include/linux/fdreg.h Sat Feb 26 18:35:40 1994
@@ -49,4 +49,7 @@
 #define ST3_HA         0x04            /* Head (Address) */
+#define ST3_DS         0x08            /* drive is double sided */
 #define ST3_TZ         0x10            /* Track Zero signal (1=track 0) */
+#define ST3_RY         0x20            /* Drive Ready */
 #define ST3_WP         0x40            /* Write Protect */
+#define ST3_FT         0x80            /* Fault */
 
@@ -63,2 +66,3 @@
 #define FD_PERPENDICULAR       0x12    /* perpendicular r/w mode */
+#define FD_GETSTATUS           0x04    /* read ST3 */

------------------------------

Date: 27 Feb 1994 16:38:00 +0100
From: [email-masked] (Kai Henningsen)
Subject: Re: Specialix driver

[email-masked] wrote on 27.02.94 in <[email-masked]>:

> >    Let's say I run Linux, and one of it's system calls is unique to the OS
> >(It could be another OS like VSTa for example).  If I use that unique
> >system call, would my code need to be GPLed under the GPL?  I'm not exactly
> >sure if Linux has unique (non-public) syscalls, but couldn't that
> >potentially cause problems?
>
> That's my understanding, yes.  So, you should be *really* careful to
> make sure you just use POSIX interfaces.  Then there should be no
> problem.

Since this only revolves on the definition of "derived work", not on the  
GPL as such (in fact, the GPL seems to explicitely say something quite  
different about what a "derived work" is), let's transport it to another  
copyright holder.

Is every Windows program a derived work from Windows?

Kai
--
Internet: [email-masked], [email-masked]
Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai}
## CrossPoint v2.93 ##

------------------------------

Date: 27 Feb 1994 16:39:00 +0100
From: [email-masked] (Kai Henningsen)
Subject: Re: Specialix driver

[email-masked] wrote on 27.02.94 in <[email-masked]>:

[By the way, you completely ignored the relevant part of the GPL I quoted.  
What about it? Does it say what it seems to say? If not, why not?]

> The FSF got mad and their lawyers contacted NeXTs lawers, or something
> like that.  In the end it was determined that since you couldn't use
> those .o files without linking them to GPLed sources, they were
> obviously a derivative work and so they fell under the GPL as well.

Still a different animal. The linking process produces something that's  
quite different from the original, so much that it no longer does what the  
original did. At least, as much as I can see.

That's a lot different from a simple addition.

Furthermore, it seems it never got to court? Then it's not useful to show  
what the law is ...

Anyway, it's questionable if what the FSF thinks has any bearing on this  
discussion, as she doesn't hold the copyright in question anyway. Linus  
does.

Moral: while using the GPL, keep the copyright to yourself.

Kai
--
Internet: [email-masked], [email-masked]
Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai}
## CrossPoint v2.93 ##

------------------------------

From: [email-masked] (Thomas Pfau)
Subject: Re: [Q] Is there Shared Library for GNU Readline ?
Date: 27 Feb 1994 18:18:35 -0500

sunsite.unc.edu:/pub/Linux/libs/librl-1.2.tar.gz
                                librl.README
-- 
tom_p                           | I could get a new lease on life
internet:   [email-masked]  | if only I didn't need the first
compuserve: 73303,1136          | and last month in advance.

------------------------------

** 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: [email-masked]

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: [email-masked]

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