Subject: Linux-Development Digest #798
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:     Mon, 6 Jun 94 06:13:05 EDT

Linux-Development Digest #798, Volume #1          Mon, 6 Jun 94 06:13:05 EDT

Contents:
  Re: Let's rename v1.0.9! [Was: Frustrated with new kernels] (Andrew Walker)
  kernel init bug (Kenneth J. Hendrickson)
  DOS program to read Linux EXT2FS partition? (JoSH Lehan)
  SOLVED: /dev/audio busy (Harald Albrecht)
  Re: Compile problems with stock kernel.. (James LewisMoss)
  Re: Keyboard: Handicapped access driver desired. (Andries Brouwer)
  Re: Looking for mprotect() (Steven Buytaert)
  Re: Linux/SCO compatibility? (Jens Krauss)
  DIP: Aborts with Errors. Help! (fox@otago.ac.nz)
  kernel init bug (Kenneth J. Hendrickson)
  kernel init bug (Kenneth J. Hendrickson)
  Re: Let's rename v1.0.9! [Was: Frustrated with new kernels] (Kevin Brown)

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

From: andy@eng.kvaerner.no (Andrew Walker)
Subject: Re: Let's rename v1.0.9! [Was: Frustrated with new kernels]
Date: 6 Jun 1994 03:51:20 -0400
Reply-To: andy%eng.kvaerner.no@uunet.uu.net


Dan Naas (dan@oea.hacktic.nl) wrote:

| I think Linus should make it a bit more difficult to get the development
| kernels. A hidden directory advertised only on the kernel channel is a
| good idea, IMHO. This way, if somebody goes to the trouble of getting the
| latest kernel release, s/he can't claim ignorance.

Careful with this! There are a lot of people out here who rely on more
or less "broken" ftp-by-mail servers. When I say "broken" I mean that
they tend to barf on directories they can't see. You wouldn't want to
exclude people just because their employers are too paranoid to run
a decent net connection, now would you (speaking from experience ;-).

-Andy
-- 
Andy Walker                              Kvaerner Engineering a.s.
Andrew.Walker@eng.kvaerner.no            P.O. Box 222, N-1324 Lysaker, Norway

Andrew.Walker%eng.kvaerner.no@uunet.uu.net <- You'll probably need this outside
                                              Europe :-(

   ......if the answer isn't violence, neither is it silence......


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

From: kjh@pollux.usc.edu (Kenneth J. Hendrickson)
Subject: kernel init bug
Date: 6 Jun 1994 02:09:56 -0700

I just wiped Yggdrasil off my disk, and installed slackware from the
infomagic CD rom.  There are bugs at boot-up.  The kernel is passing
options to init that init shouldn't get.

My apologies if I'm posting a solution to an already solved problem.  I
don't read this group.  Here is a patch to /usr/src/linux/init/main.c

*** linux/init/main.c.orig      Mon Apr 11 21:02:14 1994
--- linux/init/main.c   Mon Jun  6 02:40:15 1994
***************
*** 296,312 ****
                                        break;
                                }
                        }
!               } else if (!strcmp(line,"ro"))
                        root_mountflags |= MS_RDONLY;
!               else if (!strcmp(line,"rw"))
                        root_mountflags &= ~MS_RDONLY;
!               else if (!strcmp(line,"debug"))
                        console_loglevel = 10;
!               else if (!strcmp(line,"no387")) {
                        hard_math = 0;
                        __asm__("movl %%cr0,%%eax\n\t"
                                "orl $0xE,%%eax\n\t"
                                "movl %%eax,%%cr0\n\t" : : : "ax");
                } else
                        checksetup(line);
                /*
--- 296,316 ----
                                        break;
                                }
                        }
!               } else if (!strcmp(line,"ro")) {
                        root_mountflags |= MS_RDONLY;
!                       continue;
!               } else if (!strcmp(line,"rw")) {
                        root_mountflags &= ~MS_RDONLY;
!                       continue;
!               } else if (!strcmp(line,"debug")) {
                        console_loglevel = 10;
!                       continue;
!               } else if (!strcmp(line,"no387")) {
                        hard_math = 0;
                        __asm__("movl %%cr0,%%eax\n\t"
                                "orl $0xE,%%eax\n\t"
                                "movl %%eax,%%cr0\n\t" : : : "ax");
+                       continue;
                } else
                        checksetup(line);
                /*

-- 
"Arguing about predestination is virtually irresistible."    --RC Sproul
Ken Hendrickson N8DGN/5           kjh@usc.edu           kjh@seas.smu.edu

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

From: jlehan@galaxy.csc.calpoly.edu (JoSH Lehan)
Subject: DOS program to read Linux EXT2FS partition?
Date: Mon, 06 Jun 94 09:09:50 GMT

Is there a MeSs-DOS program out there that will access Linux EXT2FS
partitions?  This would be *very* useful...  I've trashed my /etc/passwd so
many times I've memorized what cylinder, head, and sector the file's at
(thank goodness for low-level disk editors that bypass DOS).

I'm looking for info on how the EXT2 filesystem is laid out: where the
superblocks are, the fields in them and how they are related to the rest of
the filesystem, the inodes and how they map to the directory structure and
the files, etc.  If there isn't a MeSs-DOS program to read Linux partitions
already, this would be something more to add to my list of stuff I want to
do when I finally get the time...  :-)

Josh
-- 
       ______   printf("\x1B[1;35m\x1F\x1B[0m");         "ItSnOtYoUrS!  /\
JoSH Lehan  /                                             iWaNtItBaCk!"/{}\
jlehan@galaxy.csc.calpoly.edu or jlehan@oboe.aix.calpoly.edu          /~~~~\
         \/                                  ^^^ Use Linux instead!  /______\

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

From: albrecht@igpm.rwth-aachen.de (Harald Albrecht)
Crossposted-To: comp.os.linux.admin,comp.os.linux.help
Subject: SOLVED: /dev/audio busy
Date: 6 Jun 1994 08:56:25 GMT

Hi netters!

PROBLEM:
Some other people also seem to have the same problem: they could successfully
compile a new kernel with sound support and create the necessarz /dev/xxxx
stubs. But whenever I try to cat a sound file (cat sound.au > /dev/audio)
all I get is the error message "device busy".

SOLUTION:
This patch only solves the problem if you're using DMA #0 with your
sound card (SoundBlaster 17 for example). The bug is with dma.c in the
kernel sources. The author of this piece of code believes that DMA channel
0 is reserved for DRAM refresh. But this isn't true any more for modern
386/486 boards which use their own refresh logic.

Edit /usr/src/linux/kernel/dma.c:

static volatile unsigned int dma_chan_busy[MAX_DMA_CHANNELS] = {
                1, 0, 0, 0, 1, 0, 0, 0
};

Replace the first 1 with a 0. That enables DMA #0. But don't do the
same with DMA #4. This is cascade and won't work! The code should
look like this:

static volatile unsigned int dma_chan_busy[MAX_DMA_CHANNELS] = {
                0, 0, 0, 0, 1, 0, 0, 0
};

Then recompile and reboot with the new kernel. Enjoy it!

Harald Albrecht
albrecht@igpm.rwth-aachen.de

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

From: moss@usceast.cs.scarolina.edu (James LewisMoss)
Crossposted-To: comp.os.linux.admin
Subject: Re: Compile problems with stock kernel..
Date: 6 Jun 1994 03:42:12 -0400

jimr@shorty.cs.wisc.edu (Jim Robinson) writes:

>In article <1994Jun5.070716.5804@clark.dgim.doc.ca> root@orion.docwhitehorse.doc.ca (root) writes:
>>I just downloaded the stock version 1.1 kernel from sunsite.unc.edu, and am
>[...]
>>various patches from 1 to (at the time current) 15, and that appeared to
>>make the problems worse.. <sigh>.. 

>IMO this is a bad idea.  Go and get the pre-patched 1.1.13, and apply
>the patchs up to 1.1.18 instead.  pl12 killed some things due to a few
>mistyped words.  I know you can get it at ftp.funet.fi, I don't know
>about any other sites (since I don't *visit* any other sites :).

>Jim
>jimr@simons-rock.edu

I've also seen (and compiled) a 1.1.16 source tree as well.  patch17
went onto this source tree no problems.

jim


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

From: aeb@cwi.nl (Andries Brouwer)
Subject: Re: Keyboard: Handicapped access driver desired.
Date: Mon, 6 Jun 1994 08:13:12 GMT

thantos@runic.mind.org (Alexander Williams) writes:

: I believe that I might need someone to actually craft a special driver for
: my systems needs. Soon, I will be xlating this system over to Slackware 
: Linux, and as such, will be needing the same functionality I get from my 
: current DOS system under Linux. Being one of the handicapped users of the 
: system, I can only use one finger to type with, and have a special TSR 
: under DOS, and special keyboard drivers under Windows to cause the shift, 
: ctrl, and alt keys to become toggles.

: Has something of similar caliber been written for Linux?

It is a standard part of Linux already.
Using loadkeys you can make your keys mean whatever you want.
Some of the meanings that you can choose are Shift_Lock, Control_Lock, etc.
So, after saying
% loadkeys
keycode 29 = Control_Lock
keycode 42 = Shift_Lock
%
your left Control and Shift keys will act as toggles.
The numbers involved are revealed by showkey
(and are 29, 97, 42, 54, 56, 100 for left and right control,
shift and alt, respectively), and the functions are
Control_Lock, Shift_Lock, Alt_Lock, ALtGr_Lock.

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

From: buytaert@imec.be (Steven Buytaert)
Subject: Re: Looking for mprotect()
Date: Mon, 6 Jun 1994 08:36:45 GMT

David J. Hughes (bambi@kirk.Bond.edu.au) wrote:
: Has anyone developed a working mprotect()?  As of the latest kernel,
: it's still an empty function flagged as being unimplemented.  I need it
: for a debugging library I use for tracking memory problems in my code.
: I decided to offer Linux as a supported platform for my work and need
: the debugging library to ease the porting process.
: I'd prefer to find someone who's done this rather than start from scratch.
: If there's been no work on it yet then I'll probably have to put one
: together myself.

  I've done it. There are a few things to watch out for
  though...

  - I have an mprotect() that works for my application.
    That means, all my testprograms work. If it will work
    with Electric Fence, I don't know. Someone has asked
    me for my patches and said that some things worked and
    some didn't. That's possible...
    Currently, I don't have the time and the urge anymore
    to try and fix it. If someone wants to have it, I'll
    upload it somewhere and make an announcement in c.o.l.a.
    (Together with a version of Texas for Linux)
  - Making mprotect() work involved some (small but subtle)
    changes to the mm stuff. Since this is at the core of the
    kernel, you should use this implementation with CAUTION.
    Several people are running it already, but, when you
    try it, you're on your own...
  - I only have the patches for a 1.1.18 kernel ready. I did
    patches for other versions, but I don't keep them in sync.
    Having to repatch the latest kernel over and over again
    is already taking some time.

  Give me a few days to get things into shape to upload. Some
  other people were interested too and I want to test things out
  before uploading...

  Stef

  P.S. Please, when you send me mail, included the e-mail address
       in your footer. I forward my personal mail that arrives at
       my work to my home address and the reply address from the
       mail header get's stripped. Someone asked me information
       about Texas on Linux last week and I can't find his e-mail
       address in the message...

--
Steven Buytaert 

WORK buytaert@imec.be
HOME buytaert@innet.be

        'Imagination is more important then knowledge.'
                        (A. Einstein)

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

From: krauss@charlie.igd.fhg.de (Jens Krauss)
Subject: Re: Linux/SCO compatibility?
Date: 3 Jun 1994 13:55:18 GMT
Reply-To: igd.fhg.de

In article <2s4lt3$etp@rs18.hrz.th-darmstadt.de>, wosch@rbg.informatik.th-darmstadt.de (olav woelfelschneider) writes: 
> > | Also, will binaries from other Unix systems run under Linux?  i.e SCO?  > > > BSD SunOS  
> > SunOS???  What makes you think a Sparc binary would work?
> Errrrhm, there once was a Sun386i machine, running SunOS ...
> Sorry, but I had to mention this...
> Olav

Sorry, but there is also Solaris2.1 for i386.....!
But that`s SVR4!!!

ciao Jens

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

From: fox@otago.ac.nz
Subject: DIP: Aborts with Errors. Help!
Date: Mon, 6 Jun 1994 07:04:47 GMT

Hay all,
 
I have the following problem.
 
Trying to setup a dial-IN SLIP link, using DIP-3.3.7-uri (05 Apr 94)
 
After remote login via a 0-modem cable on ttyS0, using AGetty on the server,
DIP is invoked by a Shell assignment in the passwd file which looks like this:
 
(passwd)
SMyname:password:502:100:Me on Remote:/home/SMyname:/bin/dip-i
 
(where dip-i is a small executable calling DIP with -i )
The DIP program(s) and in the /bin directory.
 
So, after logging I get the following message:
 
Your IP address is 44.147.240.23, Server address is 44.147.240.22.  Starting
SLIP.
DIP: tty_notlocal cannot setsid: Operation not permitted
DIP: tty_notlocal cannot TIOCSTTY: Bad file number
DIP: tty: set_state: Bad file number
DIP: tty_notlocal cannot clr CLOCAL: Bad file number
 
(and back on the login prompt)
 
IP addresses are OK.
 
It looks like it is missing a file..? But I have set all files according the
'manuals'
 
>> Additional info. I just switched back to the copies of the program which are
in the
/sbin directory (where they originally are installed). I changed the line in
the 
passwd file to addapt to that. Now, after login, I get a big delay, of several
minutes,
and then the same errors.
 
What is worse, it seems to corrupt my hard disk partition: I get errors during
reboot, 
which are fixed at that time.
 
 
Any help welcome: I am stuck.
 
Greetings, Bart Kindt, Dunedin, New Zealand.
 


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

From: kjh@seas.smu.edu (Kenneth J. Hendrickson)
Subject: kernel init bug
Date: Mon, 6 Jun 1994 08:58:41 GMT

I just wiped Yggdrasil off my disk, and installed slackware from the
infomagic CD rom.  There are bugs at boot-up.  The kernel is passing
options to init that init shouldn't get.

My apologies if I'm posting a solution to an already solved problem.  I
don't read this group.  Here is a patch to /usr/src/linux/init/main.c

*** linux/init/main.c.orig      Mon Apr 11 21:02:14 1994
--- linux/init/main.c   Mon Jun  6 02:40:15 1994
***************
*** 296,312 ****
                                        break;
                                }
                        }
!               } else if (!strcmp(line,"ro"))
                        root_mountflags |= MS_RDONLY;
!               else if (!strcmp(line,"rw"))
                        root_mountflags &= ~MS_RDONLY;
!               else if (!strcmp(line,"debug"))
                        console_loglevel = 10;
!               else if (!strcmp(line,"no387")) {
                        hard_math = 0;
                        __asm__("movl %%cr0,%%eax\n\t"
                                "orl $0xE,%%eax\n\t"
                                "movl %%eax,%%cr0\n\t" : : : "ax");
                } else
                        checksetup(line);
                /*
--- 296,316 ----
                                        break;
                                }
                        }
!               } else if (!strcmp(line,"ro")) {
                        root_mountflags |= MS_RDONLY;
!                       continue;
!               } else if (!strcmp(line,"rw")) {
                        root_mountflags &= ~MS_RDONLY;
!                       continue;
!               } else if (!strcmp(line,"debug")) {
                        console_loglevel = 10;
!                       continue;
!               } else if (!strcmp(line,"no387")) {
                        hard_math = 0;
                        __asm__("movl %%cr0,%%eax\n\t"
                                "orl $0xE,%%eax\n\t"
                                "movl %%eax,%%cr0\n\t" : : : "ax");
+                       continue;
                } else
                        checksetup(line);
                /*

-- 
"Arguing about predestination is virtually irresistible."    --RC Sproul
Ken Hendrickson N8DGN/5           kjh@usc.edu           kjh@seas.smu.edu

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

From: kjh@seas.smu.edu (Kenneth J. Hendrickson)
Subject: kernel init bug
Date: Mon, 6 Jun 1994 09:06:00 GMT

I just wiped Yggdrasil off my disk, and installed slackware from the
infomagic CD rom.  There are bugs at boot-up.  The kernel is passing
options to init that init shouldn't get.

My apologies if I'm posting a solution to an already solved problem.  I
don't read this group.  Here is a patch to /usr/src/linux/init/main.c

*** linux/init/main.c.orig      Mon Apr 11 21:02:14 1994
--- linux/init/main.c   Mon Jun  6 02:40:15 1994
***************
*** 296,312 ****
                                        break;
                                }
                        }
!               } else if (!strcmp(line,"ro"))
                        root_mountflags |= MS_RDONLY;
!               else if (!strcmp(line,"rw"))
                        root_mountflags &= ~MS_RDONLY;
!               else if (!strcmp(line,"debug"))
                        console_loglevel = 10;
!               else if (!strcmp(line,"no387")) {
                        hard_math = 0;
                        __asm__("movl %%cr0,%%eax\n\t"
                                "orl $0xE,%%eax\n\t"
                                "movl %%eax,%%cr0\n\t" : : : "ax");
                } else
                        checksetup(line);
                /*
--- 296,316 ----
                                        break;
                                }
                        }
!               } else if (!strcmp(line,"ro")) {
                        root_mountflags |= MS_RDONLY;
!                       continue;
!               } else if (!strcmp(line,"rw")) {
                        root_mountflags &= ~MS_RDONLY;
!                       continue;
!               } else if (!strcmp(line,"debug")) {
                        console_loglevel = 10;
!                       continue;
!               } else if (!strcmp(line,"no387")) {
                        hard_math = 0;
                        __asm__("movl %%cr0,%%eax\n\t"
                                "orl $0xE,%%eax\n\t"
                                "movl %%eax,%%cr0\n\t" : : : "ax");
+                       continue;
                } else
                        checksetup(line);
                /*

--
"Arguing about predestination is virtually irresistible."    --RC Sproul
Ken Hendrickson N8DGN/5           kjh@usc.edu           kjh@seas.smu.edu
-- 
"Arguing about predestination is virtually irresistible."    --RC Sproul
Ken Hendrickson N8DGN/5           kjh@usc.edu           kjh@seas.smu.edu

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

From: kevin@frobozz.sccsi.com (Kevin Brown)
Subject: Re: Let's rename v1.0.9! [Was: Frustrated with new kernels]
Reply-To: kevin@frobozz.sccsi.com (Kevin Brown)
Date: Mon, 6 Jun 1994 08:35:48 GMT

In article <Cqxp9G.1qs@oea.hacktic.nl>,  <dan@oea.hacktic.nl> wrote:
>Bjorn Ekwall (bj0rn@blox.se) wrote:
>: Let us rename 1.0.9 to 1.2.0!
>
>: This way, those who haven't read the notices from Linus et al
>: will go for that version, and stay away from 1.1.X...
>: That would make everyone happy, wouldn't it?  :-)
>
>I think Linus should make it a bit more difficult to get the development
>kernels. A hidden directory advertised only on the kernel channel is a
>good idea, IMHO. This way, if somebody goes to the trouble of getting the
>latest kernel release, s/he can't claim ignorance.

Look, guys, this isn't a hard problem or anything.

Where does one get v1.1 patches?  On

        ftp.funet.fi:pub/OS/Linux/PEOPLE/Linus/v1.1

right?

So instead, move v1.1 to:

        ftp.funet.fi:pub/OS/Linux/PEOPLE/Linus/ALPHA/v1.1

and keep 1.0 in:

        ftp.funet.fi:pub/OS/Linux/PEOPLE/Linus/v1.0.

And make the same changes on all sites that hold patches.  The same thing
goes for the networking code.

People who retrieve the v1.1 patches will then *immediately* know that it's
an ALPHA-stage kernel, without looking at any documentation.  No need to
protect the sources in a private directory, no need to change the version
numbers.

Anyone who knowingly retrieves v1.1 patches from the ALPHA directory and
has problems deserves what he gets if he doesn't know what he's doing.
A README file in the same directory should make it even clearer.


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


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