Subject: Linux-Development Digest #165
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date:     Thu, 14 Oct 93 09:30:42 EDT

Linux-Development Digest #165, Volume #1         Thu, 14 Oct 93 09:30:42 EDT

Contents:
  Re: To all device driver writers; boot-time messages. (Tim Smith)
  Re: Xfree vs. BIOS (Tim Smith)
  Linux version of "select" (Christian Moen)
  Re: Linux version of "select" (Linus Torvalds)
  Re: set*id (Thomas Koenig)
  Re: Questions Flamewar (Ian Jackson)
  Re: RFD: Removal of group "comp.os.linux.development" (John Henders)
  Re: CMS Jumbo (QIC 40/80) Driver Status (steven.a.falco)
  Re: The %&#$@ speaks again -or- An apology (Keith Hollister)
  Re: NO QUESTIONS HERE PLEASE / RTF FAQ (Re: -m486 doing nothing?) (Remco Treffkorn)
  Re: Questions Flamewar (Brandon S. Allbery)

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

From: tzs@stein3.u.washington.edu (Tim Smith)
Subject: Re: To all device driver writers; boot-time messages.
Date: 14 Oct 1993 08:10:44 GMT

[Followups have been set to comp.os.linux.misc, since this has nothing to
do with development.  They really should be in gnu.misc.discuss, but that
poor group has had this topic enough times in the last year!]

Donald J. Becker <becker@super.org> wrote:
>I think you are mistaking the Linux kernel GPL for the GLPL that the libraries
>are covered by.  With the GLPL a link kit distribution with proprietary object
>files is fine, but the GPL prohibits such a distribution under the "derivative
>work" clause.  Even if you excised every copyrighted inlined function from your
>object code, you code is still designed to work intimately with and
>inseparably from the Linux kernel.  As such, most courts would consider your
>link kit distribution as a subterfuge, designed only to avoid the clearly
>stated terms of the GPL.

So far, whenever this has come up on gnu.misc.discuss, no one taking the
above point of view has been able to cite a single legal source for
this interpretation.

The "designed to work intimately with and inseparably from the Linux
kernel" is not relevant, as can be seen from a few recent cases where
video game manufacturers tried to stop people from making unauthorized
games.  Copyright deals with copying -- as long as the object code does
not actually contain anyone else's copyrighted code, the author is OK.
In fact, the author is probably even OK if he does use copyrighted code,
if that code is necessary for compatibility with the kernel.  The courts
are *very* reluctant to allow copyright to be used to gain patent-like
protection, and so tend to find that things that are necessary are
not copyrightable.  For example, Accolade had to include some Sega
code in their unauthorized games to make them work, and this was found
to be perfectly OK.

As far as the subterfuge argument goes, as long as there is no GPL'ed
code in the driver, the author has not done anything to subject himself
to GPL.  It's very hard for a court to find that you've violated a contract
that you are not even a part of!  I doubt that this would even get past
the pleadings.

Finally, let's consider this derivative work stuff.  Here's what Chisum
and Jacobs say in _Understanding Intellectual Property Law_:

        To infringe an exclusive right of copyright, an accused work
        must (1) derive from the copyrighted work, directly or
        indirectly, and (2) be substantially similar in expression
        to the copyrighted work.

Most people on the net seem to overlook the second part of this: substantial
similarity.  Chisum and Jacobs say:

        The second element--substantial similarity in expression--depends
        on average lay observer or listener response.

(Some courts will allow experts rather than lay observers for checking
for substantial similarity.)

Substantial similarity will be the big hurdle in showing that a driver
infringes some kernel copyright.  Someone's going to have to get up with
a listing of the kernel and a listing of the driver, and try to point
out things in the kernel that are copyrighted and not necessary for
interfacing to the kernel, and then point out substantially similar
things in the driver.  This seems to me unlikely to get very far.

In summary, making things compatible with copyrighted things does not
violate copyright (the video game cases), it's unlikely that a driver
infringes kernel copyright if the author is careful (because deriving
is not enough -- you need substantial similarity), and if the driver
author is careful to not use GPL'ed code, he is not bound by GPL (basic
contract law).  Thus, the driver author is not likely to get in trouble
with a binary distribution.

--Tim Smith

ps: this is not legal advice.

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

From: tzs@stein3.u.washington.edu (Tim Smith)
Subject: Re: Xfree vs. BIOS
Date: 14 Oct 1993 08:41:39 GMT

David E. Wexelblat <dwex@mtgzfs3.att.com> wrote:
>> Since the makers of video cards generally always write a windows 
>> driver, would it be possible to write a program to extract the 
>> neccessary code from a windows driver to make it work with Xfree?
>> This wouldn't have to be incorporated into the Xfree program 
>> itself, but could be used to make just the driver portion, which
>> could be linked in.  Could this work?
>
>Windows == 16 bits.
>
>Unix == 32 bits.
>
>Any other questions?

Yeah, I've got a question.  Are Windows video drivers VxDs?  If so,
they are 32 bits, at least if they are for Windows Enhanced Mode.
That doens't meant the original idea would work, of course, but
it's not clear that it can be instantly dismissed.

--Tim Smith

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

From: christim@ifi.uio.no (Christian Moen)
Subject: Linux version of "select"
Date: Thu, 14 Oct 1993 09:17:48 GMT


I'm currently working on an X-based game. I'm doing most of the
development on SunOS and IRIX, but also a great deal on my PL12
Linux system.

To check for XEvents without blocking, I'm using "select".
The following function prints "foo" every half second on SunOS
and IRIX regardless of the number of XEvents caught, but this
isn't the case with Linux. I'm also printing a timevalue which
indicate the time from the previous "foo" printout, but this
value isn't correct on my Linux system.

I've taken a look at the newly released man-pages for the Linux
system calls and it says this in particular about "select" :

"NOTES : The Linux behavior with respect to timeout differs from
         other unices that don't modify it."

How does Linux "select" modify "timeout" ? And why should it do this ?

Help on this would be vastly appreciated.

Thanks in advance and for your time.

| Christian Moen - christim@ifi.uio.no - Tel: +47 32850093 |
| Larsehagan 36, N-3408 Tranby, Norway - Fax: +47 32854233 |

===== CUT ===== CUT ===== CUT ===== CUT ===== CUT ===== CUT =====

void bar (Display *display)
{
  fd_set readfds;
  struct timeval startTime, eventTime, delayTime, t1, t2;

  /* Set initial delaytime */
  delayTime.tv_sec  = 0;
  delayTime.tv_usec = 500000
  
  /* Loop forever */
  for (;;)
    {
      /* Initialise descriptor set */
      FD_ZERO (&readfds);
      FD_SET (display->fd, &readfds);
      
      /* Get start time */
      gettimeofday (&startTime, NULL);

      if (select (FD_SETSIZE, &readfds, NULL, NULL, &delayTime))
        {
          /* Get time of event */
          gettimeofday (&eventTime, NULL);
          
          /* Calculate new delay time */
          delayTime.tv_usec -= (eventTime.tv_sec - startTime.tv_sec)*1000000 +
            (eventTime.tv_usec - startTime.tv_usec);
          
          /* Fix negative delaytime due to clock inaccuracies */
          if (delayTime.tv_usec < 0) delayTime.tv_usec = 0;
        }
      else
        {
          /* Save old time and get current */
          time2.tv_sec  = time1.tv_sec; time2.tv_usec = time1.tv_usec;
          gettimeofday (&time1, NULL);
          
          /* Print "foo" and time difference */
          printf ("foo : %d\n", (time1.tv_sec - time2.tv_sec)*1000000
                  + (time1.tv_usec - time2.tv_usec));

          /* Restore delay time */
          delayTime.tv_usec = 500000;
        }
    }
}

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

From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Subject: Re: Linux version of "select"
Date: 14 Oct 1993 11:35:22 +0200

In article <1993Oct14.091748.27098@ifi.uio.no>,
Christian Moen <christim@ifi.uio.no> wrote:
>
>I'm currently working on an X-based game. I'm doing most of the
>development on SunOS and IRIX, but also a great deal on my PL12
>Linux system.
>
>To check for XEvents without blocking, I'm using "select".
>The following function prints "foo" every half second on SunOS
>and IRIX regardless of the number of XEvents caught, but this
>isn't the case with Linux. I'm also printing a timevalue which
>indicate the time from the previous "foo" printout, but this
>value isn't correct on my Linux system.

This comes up every one in a while: linux handles the select timeout
correctly, while SunOS and others don't :-).  That's the most likely
cause for your problems.  From the manual pages of SunOS 4.1.2:

BUGS
    ......

     select() should probably return the time remaining from  the
     original  timeout,  if  any,  by modifying the time value in
     place.  This may be implemented in future  versions  of  the
     system.   Thus,  it  is  unwise  to  assume that the timeout
     pointer will be unmodified by the select() call.

As this was the only documentation I had on select() when implementing
it, I naturally removed this bug, so linux does indeed return the time
remaining from the original timeout in the timeval structure.  So under
linux, the 'gettimeofday()' calls in your program are unnecessary: you
should just check how much the timeout structure changed (gettimeofday
may be more exact, though). 

If you want to have the broken ("normal") select semantics under linux,
use a function like

        int broken_select(int width,
                fd_set * readfds,
                fd_set * writefds,
                fd_set * exceptionfds,
                struct timeval * delay)
        {
                struct timeval tmp;

                if (delay) {
                        tmp = *delay;
                        delay = &tmp;
                }
                return select(width, readfds, writefds, exceptionfds, delay);
        }

and you should probably be ok.  I think.  The above code is untested as
usual.. 

                Linus

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

From: ig25@fg30.rz.uni-karlsruhe.de (Thomas Koenig)
Subject: Re: set*id
Date: 14 Oct 1993 10:20:24 GMT

tytso@athena.mit.edu (Theodore Ts'o) writes:

>   From: ig25@fg30.rz.uni-karlsruhe.de (Thomas Koenig)
>   Date: 13 Oct 1993 17:15:41 GMT

>   BSD - style setreuid has the flaw that effective userid's are inherited
>   across exec() - calls; in other words, if the executable is somehow
>   tricked into exec()ing an untrusted program, bad things can happen.

Ouch, sorry for that; I meant the real userid's.

If I drop privileges temporarily by swapping the effective and the real
userid, and get tricked into exec()ing something I should not have done, 
bad things still can happen, as in...

>   The classic example of this was the fingerd bug which overran a
>   buffer and got a shell for its pains...

[explanation of how POSIX works deleted]

>There's no replacement for careful programming!

Amen.

>   It would appear that HP has found a good solution for this; maybe it
>   would be a good idea for Linux, as well.  Here's what the HP-UX 8
>   manpages have to say:

>        int setresuid(uid_t ruid, uid_t euid, uid_t suid);

>        setresuid sets the real, effective and/or saved user ID of the calling
>        process.

>I fail to see how this would help things at all --- the only
>functionality which this grants you over what you have with the Linux
>setreuid() is the ability to set the saved setuid manually.  How does
>this help you any?  

A suid root program could set its effective and real userid to the real
user's and keep the saved userid 0.  This would make it possible to
retain the privileges later (because setresuid still works) but will
allow a safe exec(), either voluntarily or involuntarily via the
'smashed stack' scenario.

Errors in memory allocation are very common; it is not unlikely that a
knowledgable cracker with access to the source can come up with a way to
make the program exec() his own by exploiting this kind of bug.  I don't
want to worry about security in a part of a suid root program where I'm
supposed to have given up all privileges.

>I put a lot of thought into how to make Linux support both AT&T and BSD
>semantics fully ---

And did a very good job, too...

>It's hard to make something foolproof, since fools are so ingenious.  :-)

That's certainly right ;-)

Hmm... how about another idea, also stolen from HP, to reduce the need
for suid root programs?

Via the setprivgrp(2) call, the superuser can give the right to
make certain system calls to special groups.

For exaple, a call setprivgrp(10, PRIV_CHOWN) will give the group 10
(usually wheel) the right to chown files; a program which does this does
not need to be suid root; it could be made setgid wheel instead.  That
is a Good Thing (TM) when you look, for example, at xterm, which is a) a
complicated mess and b) is suid root in order to chown the pty's, with
known and serious problems.
-- 
Thomas Kvnig, ig25@rz.uni-karlsruhe.de, ig25@dkauni2.bitnet
The joy of engineering is to find a straight line on a double
logarithmic diagram.

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

Crossposted-To: news.groups,comp.os.linux.misc
From: iwj10@cus.cam.ac.uk (Ian Jackson)
Subject: Re: Questions Flamewar
Date: Thu, 14 Oct 1993 09:46:33 GMT

In article <931013123810@nyx>, Stefan Lukka </dev/null@nyx.cs.du.edu> wrote:
>>>>>> On Wed, 13 Oct 1993 00:22:50 GMT, iwj10@cus.cam.ac.uk (Ian Jackson) said:
>
>IJ> I stand by my description of Stefan Lukka (the person who posted
>IJ> the FAQ about -m486) as an `idiot with no netiquette' (this was in
>IJ> the Keywords line of my followup).
>
>[...] The person who posted the question, [...], was NOT me.

My apologies, you are correct.  I meant to refer to Savio Lam,
<lam836@cs.cuhk.hk>.


(NB I have posted this to all the groups I posted my original message
to, but please honour the Followup-To this time.  I have answered your
posting more fully in a separate post in col.misc only.)
-- 
Ian Jackson, at home  <ijackson@nyx.cs.du.edu> or <iwj10@cus.cam.ac.uk>
PGP2 public key available on server.  Urgent email: <iwj10@phx.cam.ac.uk>
2 Lexington Close, Cambridge, CB4 3LS, England;  phone: +44 223 64238

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

Crossposted-To: news.groups
From: jhenders@jonh.wimsey.bc.ca (John Henders)
Subject: Re: RFD: Removal of group "comp.os.linux.development"
Date: Wed, 13 Oct 1993 23:31:03 GMT

kevin@frobozz.sccsi.com (Kevin Brown) writes:

>Indeed, what we need is something like:

>    comp.os.linux.questions/help (don't know which would work better)
>    comp.os.linux.applications
>    comp.os.linux.kernel
>    comp.os.linux.admin
>    comp.os.linux.announce

>and maybe

>    comp.os.linux.applications.porting

[ followups redirected out of both news.groups, and c.o.l.d ]

    Where were you during the RFD? ;-) I argued the questions/help issue
then, and I still don't see it making much difference, but one thing I
do see, and that's that if anything, the new help group is, if anything,
more read-only than the old c.o.l was. There is very little help in .help
but lots of questions. Mostly the same questions daily. If the HOWTO's
and faq's are helping at all, I'd hate to see .help if they didn't
exist. It's volume might even exceed alt.binaries.
    Anyway, the current problem, as was raised but dismissed in the
original RFD, is that there is no well defined group for development for
and/or porting to linux. And the .development name is not well suited
for what the proposers actually wanted. 
    Unless someone can come up with a better suggestion, I would suggest
following another poster's advice, which was that rather than flaming
and fighting against something that is clearly not working well,
figuring out a way to make things work better that fit's the situation. 
    My suggestion would be the creation of _one_ new group.
c.o.l.kernel, which would be for what development was intended for. This
has several benefits. I think the name would not be a magnet like
.programmeers, or .wizards, and might even tend to keep unwanted
questions out, as a newbie would be less likely to want to read a group
appearentley for discussion of the kernel, assuming they even know what
it is.


 
-- 
John Henders       GO/MU/E d* -p+ c+++ l++ t- m--- s/++ g+ w+++ -x+
                      Segments are for Worms

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

From: falco@cbnewsk.cb.att.com (steven.a.falco)
Subject: Re: CMS Jumbo (QIC 40/80) Driver Status
Date: Wed, 13 Oct 1993 21:40:22 GMT


I had a CMS Jumbo 250 tape drive which worked when used with DOS (mostly).
It was a pain to spend 2 hours formatting a tape but it was cheap.  Then
I bought ESIX 4.0.4 and found that the CMS drive was not really
QIC-40/80 compatible.  At least it wouldn't work with either of the ESIX
drivers.  So I bought the SYSV driver from CMS.

Sometimes it would work.  Other times I would get kernel panics.  Other
times a tape would simply fail to read back.  I even sent a tape that
would not format back to 3M - they tested the tape, said it was fine,
and that the drive was at fault.

I gave up on CMS and went to an Archive SCSI drive.  It has been 100%
reliable for DOS, ESIX, and Linux.  No more time wasted formatting
tapes, and I can simultaneously use the floppies while using the tape
drive.  I know it costs more, but if ever there was a case where you
get what you pay for, this is it.  I recommend avoiding CMS drives.

        Steve Falco
        saf@whservh.att.com

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

From: keith@ursa.com (Keith Hollister)
Subject: Re: The %&#$@ speaks again -or- An apology
Date: Thu, 14 Oct 1993 02:30:38 GMT

In article <CEuB7p.7pF@ra.nrl.navy.mil> eric@tantalus.nrl.navy.mil (Eric  
Youngdale) writes:
>       Frankly, I am a little surprised that people are concerned about  
the
> bandwidth of c.o.l.d.  There are far fewer messages coming through here  
than
> there were on c.o.l before the split, and I find it quite easy to skip  
over the
> postings which I have no interest in.  Note that I do not have time to  
read any
> of the other c.o.l.* groups any more because of the enormous volume  (I  
do
> recognize that some people pay money for their newsfeed).
> 
Yeah, and it seems the ones who complain about the volume always have .edu  
domain addresses. I don't think they are paying for their newsfeed. I  
_pay_ for mine (PSI) and welcome the volume. After all, more volume means  
more interest in Linux and more potential information. Isn't this the  
general idea?

Keith Hollister
keith@ursa.com

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

From: remco@hip-hop.suvl.ca.us (Remco Treffkorn)
Subject: Re: NO QUESTIONS HERE PLEASE / RTF FAQ (Re: -m486 doing nothing?)
Date: Wed, 13 Oct 1993 02:12:29 GMT

Stefan Lukka (slukka@nyx.cs.du.edu) wrote:
...cut...
: I use quotes only for exact-word citations. You must be blind. The
: irony is that you underlined "carefully". Here is some of his post,
: use the message ID to look the article up if you don't trust me.

: +----------
: Newsgroups: comp.os.linux.development
: From: iwj10@cus.cam.ac.uk (Ian Jackson)
: Subject: NO QUESTIONS HERE PLEASE / RTF FAQ (Re: -m486 doing nothing?)
: Message-ID: <1993Oct9.161323.3288.chiark.ijackson@nyx.cs.du.edu>
: Followup-To: alt.flame
: Summary: Grrrr.
: Originator: iwj10@bootes.cus.cam.ac.uk
: Keywords: Idiot who knows no netiquette
: Sender: news@infodev.cam.ac.uk (USENET news)
: Nntp-Posting-Host: bootes.cus.cam.ac.uk
: Organization: Linux Unlimited
: References: <CEKnos.7Hy@sparc15.cs.cuhk.hk>
: Date: Sat, 9 Oct 1993 16:13:23 GMT
: Lines: 36
: +----------

: Now don't you feel stupid? As for my Reply-To header, I have the right
: not to bothered, don't I? It doesn't prevent you from sending me mail,
: but it's a hint that I won't read personal replies in this subject, so
: get the hint, will ya? The accusations at the end of your article are
: completely uncalled for, and you could be liable for defaming my
: character.


: Stefan J Lukka

No, I really do not. Thanks to using tin I have to make an extra effort
to see the full header. If I would feel stupid whenever somebody else is
right I'd have a real bad life. The thing is, I am really laid back and
smile alot. That is also why I am putting smileys at the end of sentences
that are not meant matter of factly. You elected to post to this subject
in a way that asked for replies. You 'hinted' that you would not read mail
replies to it. You 'forced' me to reply here in public. Then you come back,
having obviously read the public reply and posted again, not using private
email. Forcing everybody to read my dribble again. So you do not seem to
be THAT uninterested in following up this subject.

In fact I get the feeling that you are enjoying this. I think it is time
to stop now. Let us do it:

        I apologize to Stefan J Lukka for having caused him grief. I never
        meant to shed any bad light on his character. I made the mistake
        to judge him by his actions, which I might have misinterpreted.
        I will not do it again, therefore I have put him in my kill-file
        (second entry after Jesus Monroy) and will kill the current threat.
        However I will gladly accept e-mail and take full responsibility
        for any flames I have coming. (except from Stefan J Lukka, whose
        mail will get automatically killed, so I will not get tempted to
        send HIM email that he does not want).

I hope this apology is acceptable and I hope the community will not shun
me for having comitted the ultimate sin of having fallen for flame bait.

Remco

-- 

Remco Treffkorn, DC2XT
remco@hip-hop.suvl.ca.us   <<-- REAL reply address !!
(408) 685-1201

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

Crossposted-To: comp.os.linux.misc
From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: Questions Flamewar
Date: Thu, 14 Oct 1993 12:02:53 GMT

In article <1993Oct14.100434.3680.chiark.ijackson@nyx.cs.du.edu> iwj10@cus.cam.ac.uk (Ian Jackson) writes:
>In article <931013123810@nyx>, Stefan Lukka </dev/null@nyx.cs.du.edu> wrote:
>>[...] there you go again insulting one linux user after another and
>>calling them names (idiot, crab, ..etc.).
>
>Here is not the right place to discuss my personal opinions of these
>people.  As I said in the posting you were following up (please read

The most misplaced, inapproprate flame-posts I have yet seen in the c.o.l
hierarchy have been consistently posted by one person.  His name is Ian
Jackson.  c.o.l.d's self-appointed post-moderator has yet to do anything about
him yet....

Ian, I suggest that if you can't behave any better than the people you are
complaining about then you should *quit* complaining about them.  At the
moment it's your own flame-post (at least the second one in a week) that's
chewing up most of the volume in c.o.l.d.  And it should never have been
posted in the first place, because it was nothing *but* a flame.  This is the
proper netiquette whose lack you were in part flaming about?

++Brandon
-- 
Brandon S. Allbery         kf8nh@kf8nh.ampr.org          bsa@kf8nh.wariat.org
"MSDOS didn't get as bad as it is overnight -- it took over ten years
of careful development."  ---dmeggins@aix1.uottawa.ca

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


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