Subject: Linux-Development Digest #584
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:     Sun, 27 Mar 94 20:13:08 EST

Linux-Development Digest #584, Volume #1         Sun, 27 Mar 94 20:13:08 EST

Contents:
  Re: Proposal - Coordinating bug fixes with enhancements. (Harvey J. Stein)
  Floppy Device Driver Hung System (andy@piziali.lonestar.org)
  sendmsg and recvmsg under linux (Mahesh Neelakanta)
  Re: Mapping the text screen into user space (i.e. KDMAPDISP, mmap, etc): SOLVED!!!! (Matthias Urlichs)
  Re: 486DLC support anyone? (Raymond E. Rogers)
  Re: TCP/IP-Bug in 1.0 Kernel? (Rene COUGNENC)
  Re: How to use VARARGS under Linux ? (Rene COUGNENC)
  starlan / pcnau ethernet drivers? (root@jaxnet.com)
  Re: bug/feature in fcntl syscall (Frank Lofaro)
  Re: unsupported keys (scancode (xx) not in range 00 - 5f) (Andries Brouwer)
  Re: How to use VARARGS under Linux ? (mhomer@desire.wright.edu)

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

Subject: Re: Proposal - Coordinating bug fixes with enhancements.
From: hjstein@sunset.huji.ac.il (Harvey J. Stein)
Date: 27 Mar 94 17:06:50

In article <1994Mar23.014820.798@compiler.tdcnet.nl>
jvoosten@compiler.tdcnet.nl (J.S. van Oosten) writes:

   Harvey J. Stein (hjstein@sunset.huji.ac.il) wrote:

   : The way I see it, there are two general classes of changes that are
   : made, namely bug fixes & enhancements.

   I don't see it as strict: a lot of time short enhancements are included,
   often a few lines of code that run faster or better as it should be, but
   you can also see them as fixes then.

   And in most cases, enhancements are shipped together with bugsfixes in a
   single patch, and otherwise your coherency with the "real" sources would
   break down very soon.

Yes, I do understand that the two classes overlap.

   : My idea is to use a version number scheme that basically marks where
   : the enhancements occur.  It wouldn't be so different than the current
   : method of numbered & lettered patch levels, except that there would be
   : meaning in when the numbers & letters change.

   : We could keep track of enhancements versus bug fixes by having
   : versions consisting of four numbers (like internet addresses).  We'd
   : have Linux Version a.b.c.d, where c & d would be left out when they're
   : zero.  The meaning would be as in the following example:

   Needlessly complex. Heck, if I save those patches on MS-DOS floppy I want to
   spend a few letters on the word 'kernel' or 'linux' or something like that,
   not a big row of numbers !

Yes, I agree that this was needlessly complex.  My first proposal was
bad.


   : Maybe pl<number> would be a minor release,
   : just including bug fixes, pl<number><letter> would represent an
   : enhancement when <letter> is a-l & bug fixes only from m-z, so that
   : pl<n+1> is the same as pl<n><letter>, where <letter> is the last
   : kernel in the pl<n> series, after bug fixes have been going in for
   : afew lettered releases.

   Excuse my sarcasm, but how are you going to explain to a relative new person
   in Linux that pl103f could actually be newer than pl103q ??

That's not what I meant.  I meant that new features would only be
allowed into the first 12 patches (pl<x>[a-l]), and bug fixes would
only be allowed into the remaining patch levels (pl<x>[m-z]).  The
patches would still obey condition that pl<x><y> is older than
pl<x><z> when y < z.

   : Or, we could use even and odd.  Even numbered patch levels could be
   : the kernels where enhancements go, and odd numbered patch levels could
   : be bug fix only kernels.  I think I like this last alternative the best.

   Hmm, and get questions like: "I've seen pl103a, b, c & e, but where's 'd' ?"

No.  I meant that pl103a, b, c, ... would be enhancements & bug fixes,
and at some point, development would switch to pure bug fixes with
pl1041, b, c, ...

   : If people want to make this even stronger, they could even do as was
   : done with version 1.0, namely having well defined times where
   : enhancements are allowed in.

   Now there's a point here. Since we're now (hopefully) released from the
   'taming' as we were slowing growing to 1.00 with 0.99.14abcd.. 0.99.15abcd..
   because we were running out of version numbers :-), we could now do this:

   - New features in linux Like new drivers, code for advanced things like rpc,
     and other stuff we come up with, are held back to a new major release,
     that increases the version number by 1 (so the next major would be
     linux 2.0)

   - fixes etc. increase the version by a hundreth, so we get linux 1.01, 1.02,
     1.03 and so on.

   - The last fix _before_ a new major release gets number x.99, to indicate
     that no newer fixes are expected for this release level. This would
     be a stable, thoroughly debugged version you could use on the machines
     at work, for example. The version (x+1).00, .01 .02 .. will be used
     as the next development platform.

   My .02

Well, yes, this was basically the effect that I was trying to have,
namely:

   1. That there would be alternating stages of development, one which
      only allows bug fixes, and one that also allows enhancements.
   2. That by looking at the version numbers one can tell which stage
      a given version belongs to.
   3. That version that look like "major" releases, such as versions
      1.0, 2.0, etc, be the last version at the end of a bug fix
      state.

The reason for point 3 is so that what looks naively like a big new
version (which everyone is going to run out and get), will actually be
relatively stable and trouble-free, thus reducing network messages of
the form "I just got version 5.0 & am having all these problems."

However, there are two problems with my message.  Firstly, that
most of my suggestions were quite clumsy, poor, and didn't achieve
points 1, 2 & 3.  Secondly, and more importantly, I had stupidly made
this proposal when such a scheme is already in effect (as I have been
reminded of by net posts & by email).

So, let's just let this thread die.  I forgot that this was already
handled, and so never should have posted on the subject.

Just to finalize everything, here's how things currently work:

 ----------------- Begin included message -----------

From: Linus Torvalds <torvalds@cc.helsinki.fi>
Apparently-To: hjstein@MATH.HUJI.AC.IL
Subject: Re: Proposal - Coordinating bug fixes with enhancements.
Date: Sun, 27 Mar 1994 11:44:40 +0300

In article <HJSTEIN.94Mar22183141@sunset.huji.ac.il>,
Harvey J. Stein <hjstein@sunset.huji.ac.il> wrote:
>
>We could keep track of enhancements versus bug fixes by having
>versions consisting of four numbers (like internet addresses).  We'd
>have Linux Version a.b.c.d, where c & d would be left out when they're
>zero.  The meaning would be as in the following example:
>
>Version     Status
>1.0       Major release (only bug fixes).
>1.0.0.1   Enhancement added.
>1.0.0.2   Bug fix.
...

There is already a "official" way to do this, which is

        1.0     Stable (hope)
        1.0.x   minor bugfixes

        1.1     development
        1.1.x   bugfixes, new features, more development

After 1.1.x seems to be stable, we rename the last version as

        1.2     Stable
        1.2.x   minor bugfixes

        1.3     development
        1.3.x   bugfixes, new features, more development

etc..  So even minor numbers would be stable releases, while odd minor
numbers would be development releases.  Both have patchlevels, but the
stable releases would have only bugfixes.

In fact, the above has already taken effect: there is a "v1.0" directory
on ftp.funet.fi and ftp.cs.helsinki.fi which contains the 1.0 fixes:
four small patches so far, and a fifth probably appearing today.  The
four first ones help stabilize networking on busy nets, while the fifth
one has a few assorted bugfixes.

1.0 seems reasonably stable even as it is, but the idea would be that
most people could upgrade with at least the 1.0.x patches, as those
should be safe.  The "live on the edge" people would get the 1.1 sources
(which I haven't made yet, but will make next week).

                Linus

 ----------------- End included message -----------

Although this doesn't satisfy my point 3, it is clean & simple, so
I still think it's fine.  So, as with Linux in general, the bugs have
been fixed before I even noticed them.  So we can just drop this
thread and continue work on problems which still exist. :)

Thanks,

--
Harvey J. Stein
Department of Mathematics
Hebrew University
hjstein@math.huji.ac.il

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

From: andy@piziali.lonestar.org
Subject: Floppy Device Driver Hung System
Reply-To: andy@piziali.lonestar.org
Date: Sun, 27 Mar 1994 16:55:59 GMT

   Yesterday, I inadvertently attempted to copy a 720 KB file (floppy image) to
an unformatted 720 KB 3.5 inch floppy using

        dd bs=9k if=fdImage of=/dev/fd1D720

The result was continuous attempts by the floppy device driver to write sectors
which it could not find.  /usr/log/notice reported

    Mar 26 19:58:30 piziali kernel: VFS: Disk change detected on device 2/17
    Mar 26 19:58:47 piziali kernel: floppy 1: sector not found: track 29,
      head 1, sector 3
    Mar 26 19:58:49 piziali last message repeated 3 times
    Mar 26 19:58:49 piziali kernel: Reset-floppy called
    Mar 26 19:58:49 piziali kernel: floppy 1: sector not found: track 29,
      head 1, sector 3
    Mar 26 19:58:49 piziali kernel: Reset-floppy called
        :
    Mar 26 19:58:53 piziali kernel: floppy I/O error
    Mar 26 19:58:53 piziali kernel: dev 0211, sector 532
    Mar 26 19:58:53 piziali kernel: Reset-floppy called

Attempts to kill the errant process with any signal, including SIGKILL (9),
were ineffective.  I could not log in as root to shut down the system. 
CTL-ALT-DEL, which is normally recognized by init to run shutdown(8), was also
ineffective.

   Could I have something misconfigured or is this a known problem with the
floppy device driver?  I would have expected the driver to give up after some
number of unsuccessful write attempts but, after five minutes of floppy drive
abuse, I gave up on it.  The system RESET switch was my only option.

-- 
Andy Piziali                                                    |
                                                  ________------+------________
                                                               / \
         andy@piziali.lonestar.org                            *---*

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

From: mahesh@sendai.seq.com (Mahesh Neelakanta)
Subject: sendmsg and recvmsg under linux
Date: Fri, 25 Mar 1994 23:20:43 GMT

Does linux have support for the sendmsg and recvmsg functions? It looks
like they aren't in the current kernel (1.0) + libc (4.5.21) but perhaps
someone is in the process of writing this portion of code? 

Any pointers appreciated...

thanks,
mahesh@seq.com

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

From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: Mapping the text screen into user space (i.e. KDMAPDISP, mmap, etc): SOLVED!!!!
Date: 27 Mar 1994 20:27:04 +0200

In comp.os.linux.development, article <1994Mar21.182350.5194@sendai.seq.com>,
  mahesh@sendai.seq.com (Mahesh Neelakanta) writes:
> 
> Which leads me to one final question: Can someone explain why the '<< 1' is
> needed in the code fragment below? My guess is in the comments below which
> I figured/guessed/voodoo by reading around in console.c. 
> 
Guess again.

The reason is that each position on the screen occupies 16 bits (character,
attributes). Therefore a 1-byte shift doesn't make sense, and therefore the
designers have decided to drop the low bit of the offset and shift the
register contents right one notch. You of course have to reverse that when
you read the offset.

-- 
>> To be is to do        To do is to be        Do be do be do
            (Socrate)             (Sartre)              (Sinatra)
-- 
Matthias Urlichs        \ XLink-POP N|rnberg  | EMail: urlichs@smurf.noris.de
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: rrogers@netcom.com (Raymond E. Rogers)
Subject: Re: 486DLC support anyone?
Date: Sat, 26 Mar 1994 04:09:56 GMT

In article <pm7OJWA.spu@delphi.com>,  <spu@delphi.com> wrote:
>I set up for the internal cache ( I have no external cache ) but had to
>disable it because teh cpu kept interrupting my mathco and gave me stack
>under and overflow errors, and invalid compressed format when uncompressing
>linux.  The mathco errors also occurred with dos, so I know they were not
>Linux specific.  Anyone else had this problem?  Will external cache stop it?

        Funny you should mention this.  It might be out of place but I 
have a UMC386 ISA BUS motherboard, with 486 DLC-33, 128k external 
cache, and no co-proc.  I must disable the internal cache to work 
reliably at all!  Otherwise I get random disasters.  Is there a magic 
formula for this?
        As long as I'm here, I can't get the Slackware boot disk 1_2m to
boot, so I can do a Linux installation.  This is probably due to only
having 2Mbytes, but I have read that this is possible.  If there is a
special flag to deal with this I can't find it ( for Slackware ).  I've
also downloaded and read 1MB of docs and found no help.  Could somebody
steer me in the right direction; I'm short of money now and will probably
have to live with 2Mbytes for a while. 

Ray

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

From: rene@renux.frmug.fr.net (Rene COUGNENC)
Subject: Re: TCP/IP-Bug in 1.0 Kernel?
Date: 25 Mar 1994 20:24:33 GMT
Reply-To: cougnenc@hsc.fr.net (Rene COUGNENC)

Ce brave Michael Will ecrit:

> I have noticed that SLIP does work with 1.0 but has problems running
> ftp and the like with anything beyond that. I tried 1.0p2 and 1.0p4 but
> had to go back to 1.0 to work with SLIP.


Same for me, SLIP and PPP. 

--
 linux linux linux linux -[ cougnenc@renux.frmug.fr.net ]- linux linux linux 

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

From: rene@renux.frmug.fr.net (Rene COUGNENC)
Subject: Re: How to use VARARGS under Linux ?
Date: 25 Mar 1994 20:42:46 GMT
Reply-To: cougnenc@hsc.fr.net (Rene COUGNENC)

Ce brave Zenon Fortuna ecrit:

> I would like to use the VARARGS principle (to pass to a function varying list
> of arguments). I have noticed that there exists vsprintf(), exists also
> Still, I cannot compile my sample VARARGS program, because a lot of
> declarations are missing:

Avoid "varargs" when you can, it is old; use "stdarg" instead.
A typical use is

#include <necessarystuff>
#include <stdarg.h>

your_function( char *format, ...)
{
        char buf[ YOUR_SIZE ];
        va_list ap;

        va_start(ap, format);
        vsprintf(buf, format, ap);
        va_end(ap);

        do_what_you_want_whith( buf );
}

You'll get more informations in a group like "comp.lang.c", rather  than 
in the Linux kernel development group I think :-)

--
 linux linux linux linux -[ cougnenc@renux.frmug.fr.net ]- linux linux linux 

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

From: root@jaxnet.com
Subject: starlan / pcnau ethernet drivers?
Date: Sat, 26 Mar 1994 10:27:37 GMT

I have a couple of starlan ethernet cards laying around and I was wondering
if they would work with Linux.  The model number on the cards is PC NAU V4.3B
Anyone out there have this type of ethernet card working?  If so, what do I
use as the driver?


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

From: ftlofaro@unlv.edu (Frank Lofaro)
Subject: Re: bug/feature in fcntl syscall
Date: Sun, 27 Mar 94 21:04:09 GMT

In article <davem.764179351@extro.ucc.su.OZ.AU> davem@extro.ucc.su.OZ.AU (David Monro) writes:
>I discovered the following problem the other day while attempting to
>compile mtools-2.0.7 ( a suite of programs to access msdos floppies by
>attacking the raw floppy devices, avoiding having to mount them.)
>The problem is very simple - calling flock, or fcntl with appropriate
>args (same thing) on a block floppy device (ie /dev/fd0) fails with an
>'Invalid argument' errno, but works fine for regular files. However, it
>appears to work on a Sun running SunOS 4.1.1 . Is this a bug or a
>feature? If it is a bug, I suspect the cause is on line 203 of
>linux/fs/locks.c, in the routine copy_flock():
>        if (!S_ISREG(filp->f_inode->i_mode))
>                return 0;
>Is there any reason locking should be restricted to regular files?
>
>The solution, for anybody out there compiling mtools, is to simply not
>define any of LOCKF, FLOCK and FCNTL. It works fine then, if a little
>unsafely.
>
>       David Monro
>--
>Rule of Feline Frustration:
>        When your cat has fallen asleep on your lap and looks utterly
>content and adorable, you will suddenly have to go to the bathroom.
>-- 
>"We demand rigidly defined areas of doubt and uncertainty!"
>               -- Vroomfondel
>

You could try removing those lines from the kernel, and giving it a try.
It may work, it may not (it might crash the kernel, or [very unlikely] damage 
a filesystem).


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

From: aeb@cwi.nl (Andries Brouwer)
Subject: Re: unsupported keys (scancode (xx) not in range 00 - 5f)
Date: Sun, 27 Mar 1994 23:02:28 GMT

kaz@lilia.iijnet.or.jp (Kaz Sasayama) writes:

>My keyboard generates scancodes not in range 00 - 5f for some keys.
>How can I use them?

>This is the output of `showkey -s' in kbd-0.85:
...
>0x9c 
>0x7b 
>0xfb 
>0x79 
>0xf9 
>0x70 
>0xf0 
>0x7d 
>0xfd 

The 0x9c is the key up event for your Enter key. The remaining eight
look like key down and key up events for four keys. How are these keys labelled?
What brand/type keyboard do you have?
[It is customary to precede the codes for new keys with the escape code 0xe0.
Didn't you get that code? Without it I would be inclined to conjecture
codes for communication with the keyboard controller, but I only know about
0xfa (ACK), 0xfc (BAT error), 0xfe (resend), 0xff (error).]

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

From: mhomer@desire.wright.edu
Subject: Re: How to use VARARGS under Linux ?
Date: 26 Mar 94 14:31:44 EST

In article <1994Mar25.230730.13766@resonex.com>, zenon@resonex.com (Zenon Fortuna) writes:
> In article <2mvjr5$nah@news.doit.wisc.edu> tillemaj@news.doit.wisc.edu.UUCP (John Edward Tillema,&91M+soAj) writes:
>>From article <1994Mar25.031012.3079@resonex.com>, by zenon@resonex.com (Zenon Fortuna):
> [...]
>>I think this should be of the form:  (don't know what va_dcl is?)
>> 
>>void my_log(char fmt[], ... )
>>{
>>  va_list argp;
>>  
>>  va_start(argp,fmt);
>>  vfprintf(stdout,fmt,argp); /* or vsprintf(string,fmt,argp);puts(string) */
>>  va_end(argp);
>>}
>>
>>This will allow my_log to function just like a printf statement.
> 
> Fine. But I could not find any header file with the va_list or va_dcl
> declaration. Under HP-UX the declarations are in varargs.h, somebody suggested
> that under Linux there exists stdargs.h ... but I did not find it in
> SLACKWARE 1.1.2 . Maybe simply I have to copy more header files from other (?)
> distributions ?

How about stdarg.h (singular)?  Harbison and Steele 3rd edition, p. 260 lists
this as part of the ANSI C library facilities.  It is described in more
detail in section 11.4 of the same book.

I'm not on a Linux box at the moment, but I checked the /usr/local/lib
directory where GCC 2.5.8 installed its header files (on a Sun Sparc10
running Solaris 2.3, gcc stuffed its header files in /usr/local/lib/gcc-lib\
/sparc-sun-solaris2.3/2.5.8/include).  Included in this directory were
both stdarg.h and varargs.h, and both of these files appear to be
from the GCC distribution itself...

Anyway, here's hoping this is of some use.
> 
> BTW, where to find more complete set of header files for Linux (and, maybe,
> related man-pages ?) ?
> 
>       Zenon.
-- 
Mitch
mhomer@desire.wright.edu


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


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