Subject: Linux-Development Digest #819
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, 11 Jun 94 23:13:06 EDT

Linux-Development Digest #819, Volume #1         Sat, 11 Jun 94 23:13:06 EDT

Contents:
  ISDN boards for Linux (Lawrence Foard)
  AF_UNIX SOCK_STREAM not reliable under Linux! (Gautam Thaker)
  GCC __asm__ bug with %[abcd]h registers (Drew Eckhardt)
  Re: Whats changed in the serial dirver ? (Rob Janssen)
  Looking for Exodus Storage Manager. (Shinji Suzuki)
  Re: Filesystem semantics protecting meta data ... and users data (Totally Lost)
  Re: AF_UNIX SOCK_STREAM not reliable under Linux! (H. Peter Anvin)
  CD-ROM driver for Philips external CM225MS? (\rjan Derel|v)
  Re: Filesystem semantics protecting meta data ... and users data (Totally Lost)
  Visual Shell (Sami-Pekka Hallikas)
  What and where is mkimage? (Tom Griffing)
  Frustrated with new kernels (Peter Berger)
  OI and UIB on linux with gcc-2.5.8 (Peter Berger)
  Re: in2000-SCSI drivers crashed when using HD intensively (Charles E Meier)

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

Crossposted-To: comp.sys.ibm.pc.hardware.comm
From: entropy@world.std.com (Lawrence Foard)
Subject: ISDN boards for Linux
Date: Sat, 11 Jun 1994 22:08:14 GMT

A company I consult for wants to use TCP/IP over ISDN with a Linux
system. I need to find an ISDN board which has Linux drivers available,
or made by a company willing to give enough documentation to write a
device driver.

-- 
====== Call the skeptic hotline 1=900=555=5555 talk to your own personal . 
\    / skeptic 24 hours/day.     Just say no to victimless crimes.      . .
 \  / High quality Linux application development available.            . . .
  \/ Violence is a lousy substitute for sex and drugs.                . . . .

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

From: gthaker@polyphony.sw.stratus.com (Gautam Thaker)
Subject: AF_UNIX SOCK_STREAM not reliable under Linux!
Date: 11 Jun 1994 23:00:16 GMT


Some simple tests I have done with SOCK_STREAM type socket with AF_UNIX 
indicates that this is not a reliable connection. I think 
SOCK_STREAM are meant to be reliable even on under AF_UNIX.

I am running 0.99 patch 15. In my test I send 4096 bytes down the
socket and only 4095 show up on the other side. (I loop back and
wait on the missing char but one never shows up.)  The identical
pgm with AF_INET works just fine.

Gautam






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

From: drew@kinglear.cs.colorado.edu (Drew Eckhardt)
Subject: GCC __asm__ bug with %[abcd]h registers
Date: 10 Jun 1994 00:20:39 GMT

I've been playing with my PCI support a lot lately, and just 
happened to glance at the PCI BIOS support routines I'd written,
which reminded me of a nasty little bug that I'd worked 
arround

Here's a copy of the bug report I sent to the GCC bug list -


Under GCC 2.5.7 for the i486 linux platform, the __asm__ construct
doesn't handle the %[abcd]h registers correctly when they are used 
in the input/output operand fields.  Apprantly, it considers them 
equivalent to the %[abcd]l registers.  Am I doing something wrong, 
or is this a bug from the x86's peculiar register addressing?

Specifically, if you do something like this :

    unsigned char result;
    __asm__ ("" : "=bh" (result));

You get this output : 

#APP
#NO_APP
        movb %bl,-1(%ebp)


Similarly, 
    unsigned char foo = 42;
    __asm__ ("" : : "ch" (foo))

generates this code :

        movb $42,-1(%ebp)
        movb -1(%ebp),%cl
#APP
#NO_APP
-- 
Drew Eckhardt drew@Colorado.EDU
1970 Landcruiser FJ40 w/350 Chevy power
1982 Yamaha XV920J Virago

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Whats changed in the serial dirver ?
Reply-To: pe1chl@rabo.nl
Date: Sat, 11 Jun 1994 21:28:21 GMT

In <2tc392$4r@tinny.apana.org.au> ernie@tinny.apana.org.au (Ernie Elu,,015-176-001) writes:


>For a couple of weeks now I have been trying to get my AST fourport running
>with kernel versions later than 1.1.13.
>I am now trying with kernel 1.1.18 again. I have noticed you can no longer
>define the AST fourport in serial.c, after posting to the net it was
>suggested that I try the following :

>in serial.c
>#define CONFIG_AUTO_IRQ --------------> add this in source file

>modify this line (the line with #define FOURPORT_FLAGS) to look:

>#define FOURPORT_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_FOURPORT |
>ASYNC_AUTO_IRQ)

Don't do that...  use "setserial" instead.

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

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

From: suzuki@tkl.iis.u-tokyo.ac.jp (Shinji Suzuki)
Subject: Looking for Exodus Storage Manager.
Date: Fri, 10 Jun 1994 22:30:08 GMT

Did anyone port Exodus Storage Manager (either
server or client code)?

thanks,
-shinji

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

Crossposted-To: comp.benchmarks,comp.sys.sun.admin,comp.security.unix
From: idletime@netcom.com (Totally Lost)
Subject: Re: Filesystem semantics protecting meta data ... and users data
Date: Fri, 10 Jun 1994 23:14:28 GMT

In article <2t6u8dINNnhf@usenet.pa.dec.com>,
Burkhard Neidecker-Lutz <neideck@nestvx.enet.dec.com> wrote:
>>Now, after recovery and reboot, file X contains some blocks that used
>>to be in file Y... which still contain the data from file Y.
>>
>>Security breach.
>
>Maybe on UNIX V6 15 years ago.
>
>>I don't know if this is actually possible with current filesystems;
>>I'd hope not, but...
>
>Can't speak for SUN :-), but can't happen on any modern UNIX I know.
>
>               Burkhard Neidecker-Lutz

I think the three strikes and Burkhard is out posting made it clear how
the UFS filesystem can leave trash data in a users file at a crash.

On machines that ran unix V6, most were lucky to have enough memory to
have 5-10 512 byte buffers ... systems with more than 25 buffers were
fairly rare. That is barely enough for the filesystem to run without
deadlock ... there was no code room or buffer space to implement a more
robust policy ... Ken did well. I'm amazed that I ran 3-4 users
on my first unix child ... a PDP11/34 with 96KB memory, 2.5mb disk,
two dec tapes, 9trk tape, two plotters, two digitizing tablets,
two terminals, two high performance LUndy graphics subsystems,
and a dream in CalPoly San Luis Obispo.

Up until this point room for kernel code was limited by the 16bit address
space and the fact most unix machines only had 128K to 256K of DRAM
to run 16-64 users. Anything added to kernel reduced the amount of
USER dram and increased the amount of swapping.

By 1980 when the BSD team started their work on the VAX machines with
512Kbytes and larger were starting to be common, and the VAX relieved
the 17 bit address space limit from the kernel (dual 16 bit spaces
on 11/70, 45, and 44's)..

The network code which ran in user space as prcesses (done by
the arpa community at Urbana, UCLA and BBN) was re-written at
UCB to drop into the VAX kernel. and BSD was born soon after
with the native port of V7/V32 to the vax. The unix kernal then
started it's rapid transition to huge.

All systems with filesystems based upon V6/V7/SVR3/BSD have the problem.
This is nearly every system ever shipped.

Fixing the problem means major changes to the filesystem/BIO/driver
relationships, key data structures, and key kernel internal programming
interfaces including driver and FFS/VNODE interfaces.

Twice I have come close to implementing this. First at Fortune Systems
where Don (1st VP of Engr) and I wrote it into the technical part of
the business plan/ product specification in Feb/Mar 1981. In May (??)
Don and I were replaced when we told Homer Dunn (Founder) that unless the
Software team and development computer funding that were prommised 
for March be in place in May (??), we would slip first customer ship from
early Dec 81 week by week until available. Steve Puthuff and Rick Kiesig
(which replaced Don and I) abandoned this requirement while slipping the
schedule from Dec 81 to Sept 82 week by week. The software staff budget
for 5-7 seasoned programmers turned into 25 plus kids in or just
out of school - None including Rick has the experience to do what they
blindly took on. Late in the spring of 82 Homer wanted to fire all of them
for slipping HIS schedule ... seeking my advice to replace them I
told him fat chance if he wanted to deliver the product, and that he
just spent our companies reputation to build/train what would become
one of the better unix teams in the Valley. Rick choose to meet a
minimal filesystem harding requirement by using part of the BSD code.

The second time was receintly at SCO where I attempted several times
to work out a contract to do some significant re-architecting of
the UNIX kernel and filesystem for performance and scaling reasons.
After a couple false starts, ownership of the kernel technologies
was won by the London team and hopes vanished for doing anything
interesting in Santa Cruz. So what twice could have been a major
UNIX event, is still a dream and code fragments in my lab.

The the various LFS style filesystems have the promise of reliability
but the implementation tradeoffs are performance cripping for most
desk top systems smaller than the SPrite sized machines the work
was done for. Locality of data is severly compromised. At last
winters usenix wip session I gave a wake call talk on part of these issues.

Every production machine I see is killed by UNIX filesystem I/O
running at 10-20% of what it should be ... by filesystems designers
that insist on using a horse and buggy as the prototype for a space
ship. The receint software bloat caused by X/Motif applications
continues the pressure on the I/O subsystem, combined with
increadibly faster processor technology the pressure to
replace or rearchitect UNIX will continue into the 90's.

As with my comments about Raw I/O in comp.os.rsearch the critical
problem is people attempting to continue to use outdated decisions
without re-evaluation of the assumptionas and tradeoffs involved.
The current UNIX filesystem architecture is critically flawed
on all major fronts - performance, reliability and security - and
lacks key features of the main frame market it replaces.
OS work today is done mostly by follow the herd, critical thinking
is a lost art.

Either Novell and the key players need to get the clue, or UNIX
will be replaced in the passing of time (the 90's).

John


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

From: hpa@ahab.eecs.nwu.edu (H. Peter Anvin)
Subject: Re: AF_UNIX SOCK_STREAM not reliable under Linux!
Reply-To: hpa@nwu.edu (H. Peter Anvin)
Date: Sun, 12 Jun 1994 00:30:57 GMT

Followup to:  <GTHAKER.94Jun11190016@polyphony.sw.stratus.com>
By author:    gthaker@polyphony.sw.stratus.com (Gautam Thaker)
In newsgroup: comp.os.linux.development
> 
> Some simple tests I have done with SOCK_STREAM type socket with AF_UNIX 
> indicates that this is not a reliable connection. I think 
> SOCK_STREAM are meant to be reliable even on under AF_UNIX.
> 
> I am running 0.99 patch 15. In my test I send 4096 bytes down the
               ^^^^^^^^^^^^^
> socket and only 4095 show up on the other side. (I loop back and
> wait on the missing char but one never shows up.)  The identical
> pgm with AF_INET works just fine.
> 

This is a well-known problem with old Linux kernels.  I believe it has
been fixed in the 1.1 development kernels, but not in the 1.0 stable
releases.

There is a *reason* you have to tell INN your OS doesn't support UNIX
domain sockets when compiling it.  Using INET sockets over loopback
works fine, as you said.

The UNIX domain sockets were the earliest part of the Linux networking
code and was added primarily to get X to run.  Some features that were
not used under X were simply omitted, and not patched in until
recently since everyone was more concerned with getting INET sockets
to work properly, for obvious reasons.

        /hpa
-- 
INTERNET: hpa@nwu.edu               FINGER/TALK: hpa@ahab.eecs.nwu.edu
IBM MAIL: I0050052 at IBMMAIL       HAM RADIO:   N9ITP or SM4TKN
FIDONET:  1:115/511 or 1:115/512    STORMNET:    181:294/101
Laughter is the best medicine -- Quayle in '94.

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

From: tseng@lysator.liu.se (\rjan Derel|v)
Subject: CD-ROM driver for Philips external CM225MS?
Date: 9 Jun 1994 21:18:52 GMT

Has anyone written a driver for the Philips CM225MS external CD-ROM?



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

Crossposted-To: comp.benchmarks,comp.sys.sun.admin
From: idletime@netcom.com (Totally Lost)
Subject: Re: Filesystem semantics protecting meta data ... and users data
Date: Sun, 12 Jun 1994 01:37:13 GMT

Ok ... I think this thread is dead, I set the followup to comp.unix.wizards
for the lack of a better idea (a group I don't normally read, but will
subscribe to again for a short while) ... comp.benchmarks is not a good
place (which I read) neither are the linux or sun groups (which I don't).

I appologize for the last couple badly hacked up postings, I was using
vi over cu thru rlogin and was not aware of how bad the char drops were
when doing X cut and paste in the vi window. (my window was fine,
the end result sure wasn't ...) This post is being created the same
way ... I will try to be more careful.

>>After a wild strike three Burkhard Neidecker-Lutz is OUT!
>
>Like the T-1000, he magically reforms and comes back to finish off
>idletime... :-).

Good job Burkhard, without a sceptic this thread would have passed
right over peoples heads. Maybe a few stopped to think about it
along the way.

>If by vaporware you mean Advfs, better duck and cover. If you mean
>by vaporware "UFS is safe", rejoice.

vaporware is a safe modern UFS.

>       I never said UNIX users deserve corrrupt data.

Your right :)  but what did you then mean by:

        "Whoever writes sensitive data through the normal file system
         with normal semantics deserves to get corrupted data."

given 99.99% of unix users only have a V6/V7/SVRx/BSD filesystem
which most people would equate to "normal filesystems" then 
the paraphrase is factually correct, although slightly
imprecise since a very small set of users may have a filesystem
with correct operation in this case.

>Advfs does not suffer from the same problem because it keeps a ordered
>log of what metadata operations have happened. Regardless of the ordering
>of writes, the replay of the log after a crash makes sure that the
>right thing happens (including the missed block zeroing).

I suggest that if the user data is missing from the "ordered log" as
well as disk completion events then it is impossible to reconstruct
what the correct data is ... and in my mind while zeroing questionable
data may correct the security violation it does not leave the
data correct. Unless the recovery tool tells the admin and user
that it cleared a section of the file, or that a file was open
and written but not closed, then the user still can not trust
any data near the time of the crash.


>So while you are right for BSD UFS, a modern UNIX file system such as
>Advfs does it right. And that's not vaporware, that's included without
>additional fee with every DEC OSF/1 shipped since V1.3 (i.e. since mid-1993).

Please specifically address the above points before I can accept
your assesment of "right". I rather suspect that Advfs is not,
just by certain other track histories.

Can some other reader please address the same questions for the
AIX JFS?

We then can discuss "modern UNIX file system such as" at some
other point .... ;)

Make sure all you volume buyers out there call up your UNIX vendor
and ask this question ... Is my system data secure after a crash?
and be a bit questioning about the salesmans answer :)

> You don't need to do a log-structured file system to get the
> reliability associated with keeping a log. Advfs (and as far as
> I know, JFS in AIX) are not log-structured.

What I forgot or should have said, is that I think you can get
LFS or better performance on small systems without implementing
a log at all, and still have reliability. And in fact I believe
designs based on the log structured approach are fundamentally
flawed due to the absense of locality, as is UFS in it's cylinder
group balancing.

> >The current UNIX filesystem architecture is critically flawed
> >on all major fronts - performance, reliability and security - and
> >lacks key features of the main frame market it replaces.
> >OS work today is done mostly by follow the herd, critical thinking
> >is a lost art.
> 
> Maybe in the UNIX Sys V crowd, not here.
> 
>               Burkhard Neidecker-Lutz
> 
> Distributed Multimedia Group, CEC Karlsruhe 
> Advanced Technology Group, Digital Equipment Corporation
> neideck@nestvx.enet.dec.com

as heralded by the great state of the midwest ... Show Me!

and remember ... It's not what you think you know that counts,
It's what you don't know about what you think you know that does!

and you can quote me!

have fun ...
John




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

From: semi@dream.nullnet.fi (Sami-Pekka Hallikas)
Subject: Visual Shell
Date: Sat, 11 Jun 1994 00:40:10 GMT

Does anyone know where can I get newest vsh (Visual Shell) for Linux? I saw
that in Coherent system some time a go, but I cannot find that "new" version
from anywhere. From nic.funet.fi I got one old vsh, but it was from year -83
or -85, so it look like that also.

--
+--------------------------+----------+-------------------------------------+
| semi@dream.nullnet.fi    |  OH1KYL  | MAIL MEDIA. Do Not Expose to Flame! |
| samip@freeport.uwasa.fi  +----------+-------------------------------------|
| semi@freenet.hut.fi      |  Dream World BBS * 358-21-4389843 * 24H * 9600 |
+---------------------------------------------------------------------------+
+-         Linux version 1.0.8 (semi@dream.nullnet.fi) #1 16-Apr-94        -+
+-   Linux.  A copylefted Unix-like operating system for the 386 and 486   -+
+---------------------------------------------------------------------------+

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

From: tom@metronet.com (Tom Griffing)
Subject: What and where is mkimage?
Date: Sun, 12 Jun 1994 01:30:32 GMT

I set out to compile X11R6 on Linux the other day and 
it errored out because it couldn't find a program
called "mkimage".  I grepped the faqs and found some
reference to mkimage and DLL's.

Can some kind soul give me some information on this
and a pointer to where I can find it?

Thanks in advance.


--
 _____________________________________________________
| Thomas L. Griffing       |  Dallas Softworks, Inc.  |
| tom@metronet.com         |  (214) 352-1011          |
|__________________________|__________________________|

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

Date: Fri, 10 Jun 1994 22:24:00 +0200
From: pit@p2.lxs.baboon.ch (Peter Berger)
Subject: Frustrated with new kernels

ewalton@magnus.acs.ohio-state.edu (Elaine Walton) wrote:

 > I have tried to compile the new kernels from off of tsx-11--no luck.
Strange..

 > I am really confused how others are able to compile, yet I am not.
 > Maybe it's because I'm trying to go from 1.0.0 directly to 1.1.13-6?
How about trying to go from 1.1.0 (note the second "1" !!!) to 1.1.19 ??

bye,
    Peter

e-mail: pit@lxs.baboon.ch


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

Date: Fri, 10 Jun 1994 22:51:01 +0200
From: pit@p2.lxs.baboon.ch (Peter Berger)
Subject: OI and UIB on linux with gcc-2.5.8

imp@boulder.parcplace.com (Warner Losh) wrote:

 > To solve this problem, you'll need to do the following.

 > First, install libc 4.5.x (this is already installed on newer machines)
 > now install OI
 > install patches to OI [*]
 > install g++ 2.4.5
 > install g++ 2.5.8
           ^^^ Typo of the month? :)
 > compile all OI applications "g++ -V 2.4.5" to use the working C++
 >  compiler.

 > [*] these patches can be found in
 > tsx-11.mit.edu:pub/linux/Packages/OI/OI-4.0-gcc-2.5.patches.tar.gz

Or did I still understand s.th. wrong?

(quoted so much, that someone just reading this may conclude himself how to
do it right.. :)

bye,
    Peter

e-mail: pit@lxs.baboon.ch


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

From: cemeier@magnus.acs.ohio-state.edu (Charles E Meier)
Subject: Re: in2000-SCSI drivers crashed when using HD intensively
Date: 11 Jun 1994 00:22:08 GMT

In article <willmore.771279741@tremplo.gis.iastate.edu>,
David Willmore <willmore@iastate.edu> wrote:
>stefan@pippi.tu-bs.de (Stefan Markgraf) writes:
>
>>Symptoms: The HD-light burns constantly. Switching between virtual consoles
>>works, but you cannot halt the system, because the HD do not work anymore.
>
>The light doesn't stay on and the consoles work.  Root is an IDE drive, so
>I can run halt, it just can't unmount the scsi drives to finish the halt.
>
>>2) Does anybody have the same problem?
>
>Yes. 
>
>Cheers,
>David

I have a similar problem.  Vanilla 1.0.9 kernel, 2 ide drives. 2nd drive has
/dev/hda6 as the swap partition.  Occasionally, after a bout of heavy
duty workload using 9meg of ram, and 16meg of swap, when the program
is finished, the drive light for the second drive comes on and does not
shut off.  Takes a shutdown to restore the system to normal.  I never noticed
this w/ 0.99.pl13 or earlier kernels.

cem

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


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