Subject: Linux-Development Digest #842
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:     Sat, 18 Jun 94 13:13:04 EDT

Linux-Development Digest #842, Volume #1         Sat, 18 Jun 94 13:13:04 EDT

Contents:
  Re: IDE PERF. PATCH SECURITY HOLE (Rob Janssen)
  Re: mmap() and files ? (Rob Janssen)
  Re: Disk-compression for Linux (Rob Janssen)
  Re: DOSEMU and Novell (Alan Cox)
  Behavior of console (Rob Ransbottom)
  Re: assembly language & Linux (ATTN!) (Colin Plumb)
  Re: DOSEMU and Novell (Andrew Anderson)
  UAR (Ernie Elu,,015-176-001)
  Yggdrasil CD-ROM question (Mr. Steve Wilkinson)
  Re: anybody working on a MULTICAST kernel? (Terje Vernly)
  Re: DOSEMU and Novell (Rob Janssen)
  Re: Filesystem semantics protecting meta data ... and users data (John F. Haugh II)
  Re: Filesystem semantics protecting meta data ... and users data (John F. Haugh II)
  Re: SCSI NCR drivers (Harald Milz)

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: IDE PERF. PATCH SECURITY HOLE
Reply-To: pe1chl@rabo.nl
Date: Fri, 17 Jun 1994 17:04:23 GMT

In <c9108932.771832337@sage.newcastle.edu.au> c9108932@sage.newcastle.edu.au (Simon Ferrett) writes:

>rob@pe1chl.ampr.org (Rob Janssen) writes:

>>In <1994Jun14.174453.28689@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro) writes:

>>>NO ONE BUY A SEAGATE 1239A. ITS CRAP! (it even got bad sectors, yeah,
>>>on an IDE drive (!), after only one year!)

>>I have enough experience with Seagate ST-225's and ST-238's to not even
>>consider buying any product from this company the rest of my life....

>I have a seagate ST3655A and it works absolutely fantastically...
>I dont think seagate is a bad compay at all - maybe you just made a couple
>of bad choices?

I have heard from others that current models are not as bad as it was
before.  However, I just don't give my hard-earned money to this company
anymore.  (after it has given me crap for my money spent earlier)
This is just my opinion and I won't change it in the foreseeable future.
However, I don't mind if anyone else buys disks from Seagate.  I don't even
mind if they throw their money in the sea.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: mmap() and files ?
Reply-To: pe1chl@rabo.nl
Date: Fri, 17 Jun 1994 17:13:50 GMT

In <RSANDERS.94Jun16232151@hrothgar.mindspring.com> rsanders@mindspring.com (Robert Sanders) writes:

>In article <PHYSADM.94Jun16170047@newton.phys.canterbury.ac.nz> physadm@phys.canterbury.ac.nz (Andrew McGregor) writes:

>   Is anybody developing an mmap() system call that can map files
>   read-write at the moment? Are there any really horrible problems with
>   doing this? I'd be interested in having a go, however it'd be useful to
>   know what has already been done.

>Well, it's difficult to do with reasonable semantics and unreasonable
>good performance, which is what most Linux users expect.  It will take
>a (further) reworking of the mm and buffer cache to do right, and no
>one wants to invest the effort in mmap() until the other subsystems
>are up to snuff.  From a Linus posting on the KERNEL mailing list:

> > > Technically, what you ask is what I had in mind.  The actual mmap
> > > syscall does not map any pages to the process, but the page fault
> > > routine looks through the list of mmaped regions to find out how to
> > > obtain the page in question.  Different types of files can have
> > > different routines for mmap - for general disk files on non-NFS
> > > filesystems there is one special function for this, and it is
> > > actually this routine that I propose be modified.
> >  
> > Actually, I'll eventually redo the whole IO subsystem: I've been
> > thinking about it for a long time, and now that 1.0 is out, I can
> > hopefully do it when I have more time. The current system works very
> > well, but has a couple of problems:
> >  - full mmap() semantics are hard to get (write mappings)
> >  - the code to handle sharing buffers etc is horribly complex
> >  
> > What I'll eventually do is just make away with the buffer cache
> > altogether, and do it all with the memory management: I have a
> > reasonably good idea on how to do this efficiently without actually
> > having to rewrite all the filesystem code.
> >  
> > The big change is to stop using "devnr, blocknr" pairs for the buffer
> > cache, and instead use "inode, pagenr" pairs in the memory management
> > code.  The advantages are legio, and the disadvantages not too bad.
> > For
> > the current page sharing, we'd need to move over the the 4kB aligned
> > executable format, but this is a longish-term project anyway.
> >  
> > And yes, it means we can cache NFS stuff with a timeout etc..  No more
> > VFS "read/write/mmap/bmap", just a "readpage/writepage" routine.
> > Swapping over NFS/msdos/whatever should also become automatic with
> > these.

>So, have a go if you wish, but coordinate with the other developers
>(especially those that read the KERNEL mailing list).

Some time ago (on his first trip) I discussed this topic with Linus as
well.  I proposed to just map the filesystem space as virtual memory,
where you could have a different selector for each partition.  The page
fault handling would bring the requested pages into real memory, and you
would never have to explicitly read something.  Just refer the pages in
your filesystem code to read them.   mmapping also cleanly fits into this.
There unfortunately are a few drawbacks:

- pointers would become 48-bit if you want direct addressing of all of
  the space.  mapping into a 32-bit area would make everything much more
  complicated again.

- the size of a partition would be limited to 4GB.  In a few years time,
  we will be complaining "how could we ever limit the size of a partition
  to a mere 4GB", just as we were complaining about the 32MB limit in
  MSDOS a few years ago.  Remember how 32MB was about 3 times the largest
  affordable disk at the time it was designed-in as the limit :-)

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Disk-compression for Linux
Reply-To: pe1chl@rabo.nl
Date: Fri, 17 Jun 1994 21:59:41 GMT

In <2tntbq$bom@kantti.Helsinki.FI> albayrak@cc.helsinki.fi writes:


>       I would like to discuss about on-fly disk compression. My
>       opinion is that implementing DoubleSpace(R) and Stacker(R)
>       -type compressing file-system is one of the most important
>       future enhancements needed for Linux.

It already exists.  Check the "double" package.
(I have no personal experience with it)

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

Crossposted-To: comp.os.linux.help
From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: DOSEMU and Novell
Date: Sat, 18 Jun 1994 11:04:44 GMT

In article <CrKAvF.2Mw@pe1chl.ampr.org> pe1chl@rabo.nl writes:
>How do you do that from a NETX or VLM running in a DOS box? (dosemu)
>You may use either packetdriver+PDETHER+IPXODI or the kernel IPX, at
>your own option, as the IPX layer :-)
>
Set the Linux box up as with a loopback network. Let NETX discover
you are on the loopback network of your host and issue each dos box
with a unique node address (eg process id 8)). Write a rip/sap daemon
for Linux IPX , season and taste

Alan



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

From: rob@phavl.uucp (Rob Ransbottom)
Subject: Behavior of console
Date: Sat, 18 Jun 1994 01:03:37 GMT

This program contains the rudiments to capture
multi-char keys from a keyboard.  The function
keys on the virtual consoles /dev/tty[1-6] behave
differently than an series of keys pressed in
close succession.

Can someone elucidate?

#include <stream.h>
#include <termios.h>
#include <stdlib.h>
#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>

const int inputFileNo = 0;
const long KEYWAIT = 500000;    // time to wait for key in microsecs.

int getKey(void);

int main( void)
{
        int c;
        struct termios initial, cur;
        tcgetattr( inputFileNo, &initial); 
        cur = initial;
        cur.c_lflag &= ~(ECHO);
        cur.c_lflag &= ~(ICANON);
        tcsetattr( inputFileNo, TCSAFLUSH, &cur);

        cout << "Press ^A to quit: Start" << endl;
        do {
                c = getKey();
        }while( c != 1 );

        tcsetattr( inputFileNo, TCSAFLUSH, &initial); 
        exit(0);
}


int getKey(void)
{
        int c, s;
        timeval waitTime;
        fd_set set;

        c = cin.get();
        cout << ">"<< char (c)<< "--(" << int(c) << ")<";
        cout.flush();

        waitTime.tv_sec = 0;
        waitTime.tv_usec = KEYWAIT;
        while (1) {
                FD_ZERO( &set);
                FD_SET( 0, &set);
                s = select( STDIN_FILENO+1, &set, NULL, NULL, &waitTime);
                if ( s == 0) {
                        break;
                }else{
                        c = cin.get();
                        cout << ">"<< char (c)<< "--(" << int(c) << ")<";
                        cout.flush();
                }
        }
        cout << "END of Char " << endl;
        return c;
}



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

From: colin@nyx10.cs.du.edu (Colin Plumb)
Subject: Re: assembly language & Linux (ATTN!)
Date: 17 Jun 1994 19:00:51 -0600

In article <2tmpm0$ejg@klaava.helsinki.fi>,
Linus Torvalds <torvalds@cc.Helsinki.FI> wrote:
> Any porters out there should feel happier knowing that DEC is shipping
> me an AlphaPC that I intend to try getting linux running on: this will
> definitely help flush out some of the most flagrant unportable stuff. 

So, who at DEC do we thank for thus supporting free software?  They're
probably not too altruistic, thinking that an AlphaPC is a very cheap
way to get a working OS, but it's nice to know that there are people in
authority that know that free software exists, and even occasionally
sells machines, and I'd like to encourage them with praise if nothing
else.
-- 
        -Colin

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

From: andersoa@news.db.erau.edu (Andrew Anderson)
Crossposted-To: comp.os.linux.help
Subject: Re: DOSEMU and Novell
Date: 18 Jun 1994 13:50:39 GMT

Alan Cox (iiitac@uk.ac.swan.pyr) wrote:
: In article <CrJH7z.KH@aston.ac.uk> evansmp@mb52112.aston.ac.uk (Mark Evans) writes:
: >This depends on what the SERVER is happy with. However I belive it is
: >the case that NT can actually do this. Not sure how it does it though,
: >possibly you need a NLM loaded on the server for it to allow a multi-
: >user client.

: Na.. its not that hard. What you have to do is make your Linux machine a 
: network not a host. Then you have 2^47 different machines on your internal
: network - that should be adequate I hope.

: Alan

Can you go into more detail on this?  Are you proposing to setup the Linux
box with its own IPX network number?  Or are you referring to TCP/IP?

--
|===========================================================================|
|  Andrew Anderson                              andersoa@erau.db.erau.edu   |
|  Novell Network System Administrator          andersoa@bart.db.erau.edu   |
|  Linux System Administrator                   andrew@wilbur.db.erau.edu   |
|                                         andrew_anderson@cts.db.erau.edu   |
|                                                                           |
| I don't speak for ERAU, and God knows I don't want them to speak for me!  | 
|===========================================================================|

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

From: ernie@tinny.apana.org.au (Ernie Elu,,015-176-001)
Subject: UAR
Date: 18 Jun 1994 11:40:50 +1000


I am trying to get the UNIX AppleTalk Router from munnari.oz.au to work
under Linux. It requires the presence of either the Berkeley Packet Filter
or some other packet filter like SUN NIT packet filter, Ultrix PF, or the
Stanford EtherNet Packet filter.

Has anyone managed to get one of these functioning on Linux ?
Or even better has anyone managed to get UAR running ?

- Ernie.
-- 
_______________________________________________________________________________

    Australian Public Access Network Association  - ernie@tinny.apana.org.au
_______________________________________________________________________________

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

From: wally@perot.mtsu.edu (Mr. Steve Wilkinson)
Crossposted-To: comp.os.linux.help,comp.os.linux.misc
Subject: Yggdrasil CD-ROM question
Date: 18 Jun 1994 14:55:49 GMT

I have an NEC3xi with a SoundBlaster 16 SCSI-II!  Yggdrasil CD-ROM does
not mount the CD.  
        q1) Is someone working on supporting this card?
                if( answer_to_q1==YES) when will an alpha or beta be avaliable 
                        and how can I get a copy?
        if(answer_to_q1==NO) 
          q2)  What other SoundBlaster cards will both Yggdrasil Linux
                CD-ROM and NEC3xi work with?
          q3)  Is someone going to add support for the SCSI-II
                SoundBlaster 16 card?
          q4)  Does anyone have specifications for SCSI-II interface for
                SoundBlaster 16?  If not where can we get them?  May be myself 
                and a friend would like to write a driver for it?  Remember we
                are poor and can't pay the $70 developer fee that CreativeLabs 
                is asking for!

Thanks in advance,
Steve Wilkinson (wally@knuth.mtsu.edu)
(known for being a planets nerd!  yes he even likes the Cyborgs!)

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

From: terjeve@ifi.uio.no (Terje Vernly)
Subject: Re: anybody working on a MULTICAST kernel?
Date: 18 Jun 94 16:26:22 GMT

With a BIG smile, taylor@stimpy.eecis.udel.edu (Howard "the Duck" Taylor) wrote:

> has anyone stared work on a multicast kernel patch?  I know of
> sunos kernels with this ability, and sgi ships their systems
> with mutlicast support...

I started implementing the IP-Multicast extensions some time ago, and I
hope to have a working multicast-kernel ready by mid-July.

TerjE

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

Crossposted-To: comp.os.linux.help
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: DOSEMU and Novell
Reply-To: pe1chl@rabo.nl
Date: Fri, 17 Jun 1994 22:09:14 GMT

In <1994Jun17.123318.11252@uk.ac.swan.pyr> iiitac@uk.ac.swan.pyr (Alan Cox) writes:

>In article <CrJH7z.KH@aston.ac.uk> evansmp@mb52112.aston.ac.uk (Mark Evans) writes:
>>This depends on what the SERVER is happy with. However I belive it is
>>the case that NT can actually do this. Not sure how it does it though,
>>possibly you need a NLM loaded on the server for it to allow a multi-
>>user client.

>Na.. its not that hard. What you have to do is make your Linux machine a 
>network not a host. Then you have 2^47 different machines on your internal
>network - that should be adequate I hope.

How do you do that from a NETX or VLM running in a DOS box? (dosemu)
You may use either packetdriver+PDETHER+IPXODI or the kernel IPX, at
your own option, as the IPX layer :-)

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

Crossposted-To: comp.benchmarks,comp.sys.sun.admin,comp.security.unix
From: jfh@rpp386 (John F. Haugh II)
Subject: Re: Filesystem semantics protecting meta data ... and users data
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Date: Sat, 18 Jun 1994 02:46:10 GMT

In article <DHOLLAND.94Jun14121255@husc7.harvard.edu> dholland@husc7.harvard.edu (David Holland) writes:
>Haven't you been following the thread? If you don't flush those zeros
>*to the disk* before using the block, a badly-timed system crash can
>cause the UNZEROED blcosk to appear in the new file - containing who
>knows what kind of private data.

Correct, but the block number can't be in the inode of the new file
without the buffered block being zeroed out.  If it isn't in the
inode, the new file can't have access to the data.  The only remaining
discussion is whether or not the inode is flushed before the data
block, and that is where the issue of "badly-timed" comes into play.

The larger, more modern systems are much more likely to have this kind
of problem (bigger buffer caches ...) than are the systems which the
original poster blamed for introducing this problem.
-- 
John F. Haugh II  [ NRA-ILA ] [ Kill Barney ] !'s: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 251-2151 [GOP][DoF #17][PADI][ENTJ]   @'s: jfh@rpp386.cactus.org
 There are three documents that run my life: The King James Bible, the United
 States Constitution, and the UNIX System V Release 4 Programmer's Reference.

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

Crossposted-To: comp.benchmarks,comp.sys.sun.admin,comp.security.unix
From: jfh@rpp386 (John F. Haugh II)
Subject: Re: Filesystem semantics protecting meta data ... and users data
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Date: Sat, 18 Jun 1994 03:46:42 GMT

In article <idletimeCrGqzv.L9L@netcom.com> idletime@netcom.com (Totally Lost) writes:
>I will go so far as to say that if a file contains any data other
>than written at a crash point it will greatly increase the
>recovery applications work for that file type. I will go on
>to say it should be required of any filesystem to indicate
>which files may be corrupt after a crash as a minimally
>required function to aid the sysadm and production staff
>to get the system consistant again short of rolling back
>to a known checkpoint..

I think that part of the reason for the rejection of your ideas may be that
they are projecting requirements that don't really seem to exist.  I
administer a number of systems and I don't make any efforts, beyond the
automated FSCK, to verify that all active files at the time of the crash
are valid.  Even in an EDP environment I've seldom seen this behavior.
The operations staff typically has a firm understanding as to which files
are safe and which aren't.  As an aside, the validity of data involves
much more than the consistency of the data from a write() call
perspective.  The filesystem will never assure more than that level of
validity.

Furthermore, I think your assertion that an async ordered write filesystem
is going to be faster a priori than the competitive mixed designs that
might be imagined seems a tad bold.  One problem which comes to mind is
that you have now created an ordering in which all metadata blocks sort
after all data blocks.  And this ordering can create thrashing as the
drive steps back out to where the data is stored (wherever that may be)
and back to where the metadata is stored (pick a cylinder, any cylinder).
My personal inclination is towards journalled filesystems, though the
state of that art seems absurd in that the I/O to the journal location
frequently appears to create its own problems.

At this point the suggestion that you prototype a filesystem based on
these concepts seems in order.  While it is true that the fully functional
design might take 3 or 4 programmer-years to implement, prototypical
implmentations should well within reach for one or two warm bodies on a
part time basis.

No doubt some of the ideas will yield promising results.  But without some
evidence, your grand re-invention seems littered with potholes.
-- 
John F. Haugh II  [ NRA-ILA ] [ Kill Barney ] !'s: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 251-2151 [GOP][DoF #17][PADI][ENTJ]   @'s: jfh@rpp386.cactus.org
 There are three documents that run my life: The King James Bible, the United
 States Constitution, and the UNIX System V Release 4 Programmer's Reference.

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

From: hm@seneca.ix.de (Harald Milz)
Subject: Re: SCSI NCR drivers
Date: Sat, 18 Jun 1994 13:23:25 GMT
Reply-To: hm@seneca.ix.de

Shahid Ikram Butt (sib1@Ra.MsState.Edu) wrote:

: > Any plans for Adaptec PCI SCSI support ?

The 294x is based on the AIC7770 chip for which support is in progress. 
-> see the Projects-FAQ soon available on sunsite. I'd guess the driver for
the 2740 should also work for the 2840 and 2940 types. Any comments on that?


-- 
Harald Milz                             office: hm@ix.de
iX Multiuser Multitasking Magazine      home:   hm@seneca.ix.de
Opinions are mine, not my employer's -- the answer is Forty-two


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


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