Subject: Linux-Development Digest #104
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Fri, 2 Sep 94 01:13:05 EDT

Linux-Development Digest #104, Volume #2          Fri, 2 Sep 94 01:13:05 EDT

Contents:
  Re: Ethernet bug
  Re: Write-Through the File System Cache? (Zygo Blaxell)
  XFconfig86 problems - HELP! (Carlos Dominguez)
  Re: [Q] How to use SCSI Generic Driver ? (Heiko Eissfeldt)
  Re: PRIORITY make an undelete command (Rob Janssen)
  Re: ext2fs corruption in 1.1.47-48 (Rob Janssen)
  Re: Ethernet bug (Rob Janssen)
  Re: DOSEMU 0.53: Developers and testers ne (Rob Janssen)
  Re: Does really Linux uses RAM efficiently? Undelete ability? (Rob Janssen)
  Re: Future of linux -- the sequel (Robert Sanders)
  Re: how to do shared C libraries (was Re: nvi 1.34, curses and the new Linux C library) (Robert Sanders)
  Re: Kernel change summary 1.1.45 -> 1.1.46 (Bill Mitchell)

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

From: [email-masked] ()
Subject: Re: Ethernet bug
Date: 1 Sep 1994 11:18:35 GMT
Reply-To: [email-masked]

Darin Johnson ([email-masked]) wrote:
: I've got 1.1.48, using a 3c509 ethernet card.  Immediately after
: rebooting, it won't respond to pings (or anything) from the
: outside world.  But as soon as I use the network locally (ie,
: ping outwards), I get the following error message and things start
: to work normally:

:   eth0: Missed interrupt, status then 2011 now 2011  Tx 00 Rx 383c.

: It's like it just needs to be kicked once to start working.
: Other info that might help is that when I boot up under dos
: it gets assigned a different ip address than under linux.

I've had the same problem for a while. I put a ping in a startup file.

Philip
--
Linux: The choice of a GNU generation!

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

From: [email-masked] (Zygo Blaxell)
Subject: Re: Write-Through the File System Cache?
Date: Thu, 1 Sep 1994 11:15:59 GMT

In article <[email-masked]>, Remy CARD <[email-masked]> wrote:
>In article <[email-masked]>,
>Matthias Urlichs <[email-masked]> wrote:
> In comp.os.linux.development, article <[email-masked]>,
>   [email-masked] (Remy CARD) writes:
> > 
> >     Maybe, I should rename the mount option from `sync' to
> > `stupid_bsd_sync'? :-)
> > 
> No, you should add another option which syncs the data.
>
>       Actually, I think that I'll soon change the ext2fs behavior.  When
>mounted with option `sync', it will do the right thing, i.e. implement
>synchronous writes on the metadata and the data.  When mounted with the
>option `bsdsync', it will implement the BSD behavior.

I'd like an option ('dsbsync'?) which does the more useful thing: write
the file data synchronously and the metadata asynchronously.

It'd also be handy if asynchronous write scheduling could do things in
that order too.  I'd rather lose 6 MB of files than have 6 MB of files
of which only 5.9 MB contain correct data.

Is there any good reason why one would want to do things the BSD way?
It sounds like a deliberate attempt to corrupt file data.

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

Crossposted-To: comp.windows.x.i386unix,comp.os.linux.help
From: Carlos Dominguez <[email-masked]>
Subject: XFconfig86 problems - HELP!
Date: Wed, 31 Aug 1994 17:46:45 GMT

Hi..

Day three, and I still cannot get X up and running on my linux box.
I'm using the slackware 2.0 distribution from the morse cd-rom.

As per the HOW-TO's I tried to run the XFconfig86 shell scripts.

I still am getting errors like "cannot cat /tmp/??????"
whenever I try to run Xfconfig86 included in my slackware 2.0 cdrom 
distribution. 

It leaves me with a 640x480 

I have read the HOW-TO's and FAQS. I am stumped.

I have read and re-read the Diamond.FAQ, and still can't get a working
Xconfig file. I have source for both a diamond proprietary clock setter
and a public non-proprietary clock setter. But what do I do now?

Can someone just hold my hand, show me how to get a working Xconfig for
my diamond stealth32 vlb (et4000 /w32p) and I will gladly post a summary
here and send it to the author of the Diamond.FAQ for inclusion.

I am in full support of the principles of the XFree86 project and the GNU
Public License. But I am stuck with a Diamond card that I must somehow use.

Thanks for reading..

--
  __  __   __ | .__.  __.  ::::  Carlos Dominguez -  Gophermaster
 |    __| |   | |  | |__   ::::  [email-masked]
 |__ |__| |   | |__| .__|  ::::  [email-masked]
 _________________________       I'm Looking for employment in the NYC area.

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

From: [email-masked] (Heiko Eissfeldt)
Subject: Re: [Q] How to use SCSI Generic Driver ?
Date: Wed, 31 Aug 1994 21:36:14 GMT

Hallo Holger,
Holger Laebe ([email-masked]) wrote:
[deleted]
: so my question :
:  - how can i send/receive data to a known SCSI Id
see below
:  - is this captured by the Generic SCSI Device
yes
:  - or is maybe already somebody working on this
don't know
: Holger

[deleted]
Thanks to Drew and Eric i got it working.

Assume you have three scsi devices with ids 0, 4, 6.
The generic device /dev/sga corresponds then to id 0,
the generic device /dev/sgb corresponds to id 4 and
the generic device /dev/sgc corresponds to id 6.

Each detected scsi device gets the next generic device.

A C source fragment follows. It has a handle_scsi_cmd routine
and the caller routine issues the INQUIRY scsi command.
It may require a newer kernel and is not complete, but should give the idea.
============================================================================
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <linux/../../drivers/scsi/sg.h>        /* ugly */

unsigned interface;
unsigned OFF = sizeof( struct sg_header ); /* size of header before buffer. */
/*unsigned OFF = 2 * sizeof( int ); /* size of header before buffer. */

/* process a complete scsi cmd. Use either generic or ioctl interface. */
static int handle_scsi_cmd(
                 unsigned cmd_len,      /* command length */
                 unsigned in_size,      /* size of input buffer inkl. OFF */
                 unsigned char *i_buff, /* input buffer */
                 unsigned out_size,     /* size of output buffer inkl. OFF */
                 unsigned char *o_buff )/* output buffer */
{
    int status = 0;
    unsigned char *buff_p;
    struct sg_header *sg_hd;

    if (!cmd_len) return -1;
    if (!i_buff) return -1;
    if (!o_buff) out_size = 0;

    if (out_size > in_size + cmd_len) {
        buff_p = o_buff;
        memcpy(o_buff + OFF, i_buff + OFF, in_size + cmd_len);
    } else {
        buff_p = i_buff;
    }

    if (interface == SCSI_IOCTL) {
        /* input buffer i_buff has size in_size + OFF. 
         * output buffer o_buff has size out_size + OFF. 
         */
        *(  (int *) buff_p     ) = in_size;      /* input buffer length */
        *( ((int *) buff_p) +1 ) = out_size; /* output buffer length */
    
        status = ioctl( cd_fd, 1 /* SCSI_IOCTL_SEND_COMMAND */, buff_p );
    
        if (status) {
    printf( "\nioctl(SCSI_IOCTL_SEND_COMMAND) status\t= 0x%x, cmd=%x\n", 
               status, i_buff[0] );
        } else
            /* get output back */
            if (out_size && out_size <= in_size + cmd_len)
                memcpy(o_buff, i_buff, out_size + OFF);
    }
    if (interface == GENERIC_SCSI) {
        /* generic scsi device services */
        sg_hd = (struct sg_header *) buff_p;
        sg_hd->pack_len = OFF + cmd_len + in_size;
        sg_hd->reply_len = OFF + out_size;
        sg_hd->pack_id = 42;    /* not used */
/*      sg_hd->flags = cmd_len; /* not used */
        
        /* write scsi command to device */
        status = write( cd_fd, buff_p, OFF + cmd_len + in_size )
            != OFF + cmd_len + in_size;
        if ( status || sg_hd->result ) {
            printf( "\nwrite(generic) status\t= 0x%x, cmd=%x\n", 
                   status, i_buff[OFF] );
            return status;
        }

        /* read results from scsi device */
        status = read( cd_fd, buff_p, OFF + out_size) != OFF + out_size;
        if ( status || sg_hd->result ) {
            printf( "\nread(generic) status = 0x%x, cmd=%x\n", 
                   sg_hd->result, i_buff[OFF] );
        } else
            /* get output back */
            if (out_size && out_size <= in_size + cmd_len)
                memcpy(o_buff, i_buff, out_size + OFF);
    }
    return status;
}

/* request vendor brand and model */
unsigned char *Inquiry ( void )
{
  static unsigned char Inqbuffer[sizeof(struct sg_header) + 56];
  static unsigned char cmdblk [10] = {0x12, 0, 0, 0, 56, 0};
  static unsigned char cmd[256];
  memcpy( cmd + OFF, cmdblk, sizeof(cmdblk) );

  if (handle_scsi_cmd(sizeof(cmdblk), 
                            0, cmd, 
                            sizeof(Inqbuffer) - OFF, Inqbuffer )) {
      FatalError ("Inquiry failed\n");
  }
  return (Inqbuffer + OFF);     /* return result of Inquiry */
}
===================================================================
Subject: Re: [Q] How to use SCSI Generic Driver ?
Newsgroups: comp.os.linux.development
References: <[email-masked]>
Organization: Virus Distribution Center
Distribution: 
X-Newsreader: TIN [version 1.2 PL2]
X-Newsreader: TIN [version 1.2 PL2]

Hallo Holger,
Holger Laebe ([email-masked]) wrote:
[deleted]
: so my question :
:  - how can i send/receive data to a known SCSI Id
see below
:  - is this captured by the Generic SCSI Device
yes
:  - or is maybe already somebody working on this
don't know
: Holger

[deleted]
Thanks to Drew and Eric i got it working.

Assume you have three scsi devices with ids 0, 4, 6.
The generic device /dev/sga corresponds then to id 0,
the generic device /dev/sgb corresponds to id 4 and
the generic device /dev/sgc corresponds to id 6.

Each detected scsi device gets the next generic device.

A C source fragment follows. It has a handle_scsi_cmd routine
and the caller routine issues the INQUIRY scsi command.
It may require a newer kernel and is not complete, but should give the idea.
============================================================================
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <linux/../../drivers/scsi/sg.h>        /* ugly */

unsigned interface;
unsigned OFF = sizeof( struct sg_header ); /* size of header before buffer. */
/*unsigned OFF = 2 * sizeof( int ); /* size of header before buffer. */

/* process a complete scsi cmd. Use either generic or ioctl interface. */
static int handle_scsi_cmd(
                 unsigned cmd_len,      /* command length */
                 unsigned in_size,      /* size of input buffer inkl. OFF */
                 unsigned char *i_buff, /* input buffer */
                 unsigned out_size,     /* size of output buffer inkl. OFF */
                 unsigned char *o_buff )/* output buffer */
{
    int status = 0;
    unsigned char *buff_p;
    struct sg_header *sg_hd;

    if (!cmd_len) return -1;
    if (!i_buff) return -1;
    if (!o_buff) out_size = 0;

    if (out_size > in_size + cmd_len) {
        buff_p = o_buff;
        memcpy(o_buff + OFF, i_buff + OFF, in_size + cmd_len);
    } else {
        buff_p = i_buff;
    }

    if (interface == SCSI_IOCTL) {
        /* input buffer i_buff has size in_size + OFF. 
         * output buffer o_buff has size out_size + OFF. 
         */
        *(  (int *) buff_p     ) = in_size;      /* input buffer length */
        *( ((int *) buff_p) +1 ) = out_size; /* output buffer length */
    
        status = ioctl( cd_fd, 1 /* SCSI_IOCTL_SEND_COMMAND */, buff_p );
    
        if (status) {
    printf( "\nioctl(SCSI_IOCTL_SEND_COMMAND) status\t= 0x%x, cmd=%x\n", 
               status, i_buff[0] );
        } else
            /* get output back */
            if (out_size && out_size <= in_size + cmd_len)
                memcpy(o_buff, i_buff, out_size + OFF);
    }
    if (interface == GENERIC_SCSI) {
        /* generic scsi device services */
        sg_hd = (struct sg_header *) buff_p;
        sg_hd->pack_len = OFF + cmd_len + in_size;
        sg_hd->reply_len = OFF + out_size;
        sg_hd->pack_id = 42;    /* not used */
/*      sg_hd->flags = cmd_len; /* not used */
        
        /* write scsi command to device */
        status = write( cd_fd, buff_p, OFF + cmd_len + in_size )
            != OFF + cmd_len + in_size;
        if ( status || sg_hd->result ) {
            printf( "\nwrite(generic) status\t= 0x%x, cmd=%x\n", 
                   status, i_buff[OFF] );
            return status;
        }

        /* read results from scsi device */
        status = read( cd_fd, buff_p, OFF + out_size) != OFF + out_size;
        if ( status || sg_hd->result ) {
            printf( "\nread(generic) status = 0x%x, cmd=%x\n", 
                   sg_hd->result, i_buff[OFF] );
        } else
            /* get output back */
            if (out_size && out_size <= in_size + cmd_len)
                memcpy(o_buff, i_buff, out_size + OFF);
    }
    return status;
}

/* request vendor brand and model */
unsigned char *Inquiry ( void )
{
  static unsigned char Inqbuffer[sizeof(struct sg_header) + 56];
  static unsigned char cmdblk [10] = {0x12, 0, 0, 0, 56, 0};
  static unsigned char cmd[256];
  memcpy( cmd + OFF, cmdblk, sizeof(cmdblk) );

  if (handle_scsi_cmd(sizeof(cmdblk), 
                            0, cmd, 
                            sizeof(Inqbuffer) - OFF, Inqbuffer )) {
      FatalError ("Inquiry failed\n");
  }
  return (Inqbuffer + OFF);     /* return result of Inquiry */
}
===================================================================
-- 
Bye                                             | computers are more dumb than
Heiko Eissfeldt                                 | humans, but smarter than 
[email-masked]                        | programmers.

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

From: [email-masked] (Rob Janssen)
Subject: Re: PRIORITY make an undelete command
Reply-To: [email-masked]
Date: Thu, 1 Sep 1994 08:14:10 GMT

In <[email-masked]> [email-masked] (Mark A. Horton KA4YBR) writes:

>John Henders ([email-masked]) wrote:
>: In <[email-masked]> [email-masked] (Rob Janssen) writes:

>: >Did you never erase a file later on the day that you first created it?
>: >Or foul it up during some edit session, making you wish that you could
>: >get back a version like it was 3 or 4 edit-sessions ago?

>:      Isn't that what rcs is for?

>               BRAVO!
>       
>       Yes, John... too bad most of the people screaming for an undelete function
>have never worked in a real software development environment that used rcs or sccs
>or some other package for revision control.   And before the flames start about 
>uncessary complexity and being "too difficult to deal with," I say bull!  If set
>up properly, a revision control system is almost invisible to the end user (the
>programmer in this case!)  One should learn and explore the tools at hand before
>screaming for others "just like they're used to".... One has to wonder if these same
>people still use edlin under DOS or have taken the bold steps necessary to master
>the newer "edit" editor!

I have done 1 project in an environment where running the editor was starting
a script that retrieved the specified file from sccs, then started your
editor, then put it back into sccs after you left the editor.
Although it addressed the above problem, it was a drag.

- The calls to sccs slowed down the edit sessions.

- After a while nobody would type relevant comments lines anymore.

- It made it extremely difficult to switch editing between a set of files
  when you had not planned the set beforehand and given it as a list to the
  edit command.

- The load on the system was enormous (this was 5 years ago).

It surely had some nice advantages, but as a whole I would never recommend
it as a project environment to anyone.  Use RCS and SCCS only to store
revisions that are somehow considered being milestones, not for each and
every file written during an edit session.
(e.g. revisions that were sent for alpha testing, or maybe one revision per
day while debugging)

This still leaves the need for a short-lived file version system in the
filesystem, i.e. comparable to what Netware and VMS do.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: [email-masked] (Rob Janssen)
Subject: Re: ext2fs corruption in 1.1.47-48
Reply-To: [email-masked]
Date: Thu, 1 Sep 1994 21:43:36 GMT

In <[email-masked]> lan_lada@rcsw52 (Marino Ladavac) writes:

>I have had the same problems while using teh 1542CF with 1.0, 1.0.9 and
>1.1.11.  Eventually I've tested the thing by directly writing to one
>of the partitions on the SCSI drive (50 MB of incrementing chars written,
>then read, and the offending char's printed.)  Some of the bits (usually
>only one per byte) get lost (inverted.)  It happens both on writing
>and reading.  I suspected a problem with 1542CF (driver or the cable) but
>it may not be.  I have had no problems (knock wood :) on the same machine
>while using IDE drives (1.0, 1.0.9, 1.1.11, 1.1.45.)  I shall have to
>check the behavior when only the card supplies the SCSI termination power,
>and when the drive is passively terminated (the drive, Adaptec and the
>cable live very happily in another machine devoted to OS/2 and DOS.)

I think it should not matter how many devices supply terminator power,
as long as at least one does.  The quality of the cable and the type of
termination can make quite some difference.

Do you have parity enabled on the SCSI bus?
Did you do the same 50MB test under OS/2 and DOS?  What happened?

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: [email-masked] (Rob Janssen)
Subject: Re: Ethernet bug
Reply-To: [email-masked]
Date: Thu, 1 Sep 1994 21:50:56 GMT

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

>Darin Johnson ([email-masked]) wrote:
>: I've got 1.1.48, using a 3c509 ethernet card.  Immediately after
>: rebooting, it won't respond to pings (or anything) from the
>: outside world.  But as soon as I use the network locally (ie,
>: ping outwards), I get the following error message and things start
>: to work normally:

>:   eth0: Missed interrupt, status then 2011 now 2011  Tx 00 Rx 383c.

>: It's like it just needs to be kicked once to start working.
>: Other info that might help is that when I boot up under dos
>: it gets assigned a different ip address than under linux.

>I've had the same problem for a while. I put a ping in a startup file.

My system at work (which has a 3c509) shows the same "Missed interrupt"
error on boot, but only when the system is rebooted without powerdown.
(CTRL-ALT-DEL reboot, e.g. after compiling a new kernel)
When I have just switched on the system it never appears.  Unfortunately
there is no RESET button on this box, so I can't tell what happens when
booting that way :-(

(this system also mounts some NFS filesystems in the startup sequence,
so there are no network reachability problems)

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: [email-masked] (Rob Janssen)
Subject: Re: DOSEMU 0.53: Developers and testers ne
Reply-To: [email-masked]
Date: Thu, 1 Sep 1994 21:53:27 GMT

In <[email-masked]> [email-masked] (Wolfgang Kalthoff) writes:

>In <[email-masked]> [email-masked] (Robert G. Smith) writes:

>>Bigfoot ([email-masked]) wrote:
>>: From where can I ftp the latest DOSEMU0.53 ? (exact filename and subdirectory
>>: please).

>>tsx-11.mit.edu:pub/linux/ALPHA/dosemu/private/devel/pre53_16.tgz

>>Specify the path all at once because the "private" dir is
>>unreadable.

>>Rob Smith

>Hi Rob,
>none of the mirrors of tsx-11 I have access to has this directory.
>Maybe "unprivate" would be better ...
>I'd like to test 0.53.

I presume the original intention of this "private" directory (there are
some others on tsx-11 as well) was to provide a place to store files
available only to a selected group of testers.  Now that everybody knows
where the pre-alpha dosemu stuff is, the whole purpose of the "private"
directory is gone and it may just as well be made readable to the
public...

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: [email-masked] (Rob Janssen)
Subject: Re: Does really Linux uses RAM efficiently? Undelete ability?
Reply-To: [email-masked]
Date: Thu, 1 Sep 1994 22:01:11 GMT

In <[email-masked]> [email-masked] (Alan Cox) writes:

>In article <[email-masked]> [email-masked] writes:
>>Linux has memory management which is on par with most commercial
>>operating systems.  I know of none with better management, in fact.
>>(Then, again I can only quote a few names that have significantly
>>worse memory management.)

>The Linux memory manager has two problems, both obscure and both present
>in every other system I've looked at so far. You can't dynamically allocate
>definitely DMA'able memory, and you can't allocate memory dynamically with
>a preference for DMA'able memory (to lower bounce buffer usage). Since you
>have to have a >16Mb ISA bus machine with a bus mastering card for this
>to matter its not that important.. just a small irritation in the perfection
>8)

It has been discussed a few times before, but every time it turned out
to be quite difficult to do it better...   Some cards can only DMA to
addresses below 1MB, a lot more can only DMA below 16MB, and some can
DMA everywhere.  Transfers via the system DMA controllers can't cross
a 64K boundary when they are 8-bit, or a 128K boundary for 16-bit
transfers.  Busmaster transfers are not restricted like that.

Alltogether this means there is a quite complicated set of restrictions
to be fullfilled for "definitely DMA'able memory", with many optional
items in the set...

The people working on the floppy code proposed using a fixed pool of
memory below 1MB, to be distributed on request from drivers that need
such memory.  That is OK for semi-permanent allocation, but it will not
work that well when a driver allocates and releases memory regularly.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: [email-masked] (Robert Sanders)
Subject: Re: Future of linux -- the sequel
Date: 01 Sep 1994 18:16:10 GMT

On Thu, 1 Sep 1994 17:03:32 GMT, [email-masked] (Lawrence Foard) said:

> You mean one of these years :) The GNU-hurd (or heard?) project has been
> going on for years before Linux was even thought of. Linux is running, the
> micro-kernel hurd is still in vapor land.

Not at all; the Hurd is up and running.  Apparently, you can even use Emacs
under it.

The Hurd is a completely different project.  You can't compare the two
as because one's a very competent but mostly traditional
re-implementation of an old operating system and the other is a fairly
new design with Unix compatibility.  The Hurd can be easily ported to
any system that runs Mach, and that's quite a few.  Linux can be
ported to any such system as well, but with a teensy bit more effort
(just ask Hamish MacDonald :-).

  -- Robert

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

From: [email-masked] (Robert Sanders)
Subject: Re: how to do shared C libraries (was Re: nvi 1.34, curses and the new Linux C library)
Date: 01 Sep 1994 16:00:30 GMT

On 1 Sep 1994 10:38:46 -0400, [email-masked] (David Barr) said:

>> Linux does that; shared libraries have major and minor revision
>> numbers.

> Sure, but the loader mechansim is significantly different than
> Solaris', so it's not really the same.

Could you be a bit less concise here?  Solaris uses ld.so to load the
shared libraries; Linux uses ld.so to load the shared libraries.
Solaris uses mmap() to map in the libraries; Linux uses mmap() to map
in the shared libraries. etc.

There is a significant difference in how symbols are resolved.  Linux
(currently) does it at link time, while Solaris does it at run time,
but that isn't really relevant to the discussion at hand.

  -- Robert

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

From: [email-masked] (Bill Mitchell)
Subject: Re: Kernel change summary 1.1.45 -> 1.1.46
Date: 01 Sep 1994 16:15:03 GMT

In article <[email-masked]> [email-masked] (Remy CARD) writes:
> 
>       In 4.4BSD, immutable and append-only flags can only be set and cleared
> in single-user mode.  It should be easy to make it work the same way in
> Linux: add a system call which specifies the run-level and modify init to
> call it when going into single user mode or multi user mode.  The problem is
> that Linux has many versions of init floatting around and such a solution
> would require that everybody upgrades his init program.
> 

If so, I would hope that this would be options.  The protection would
be useful, but a lot less useful if it were that hard to change.

--

    Bill Mitchell
    Dept of Mathematics
    The University of Florida
    [email-masked]       (904) 392-8123

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

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