Subject: Linux-Development Digest #833
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:     Wed, 15 Jun 94 19:13:07 EDT

Linux-Development Digest #833, Volume #1         Wed, 15 Jun 94 19:13:07 EDT

Contents:
  Re: Filesystem semantics protecting meta data ... and users data (Totally Lost)
  Re: Pascal compiler for Linux? (John Lellis)
  Dialer wanted (Karl Mueller)
  Dialogic drivers (pietro)
  IDE Performance Package Release? (Was Re: IDE PERF. PATCH SECURITY) (Fred Homan)
  Re: Filesystem semantics protecting meta data ... and users data (Adam Sweeney)
  Re: AF_UNIX SOCK_STREAM not reliable under Linux! (Lawrence Foard)
  Re: AF_UNIX SOCK_STREAM broken even in kernel 1.1.13. (Gautam Thaker)
  Re: IDE PERF. PATCH SECURITY HOLE (David Wright)
  Re: assembly language & Linux (ATTN!) (Brandon S. Allbery)
  Re: Pascal compiler for Linux? (Tadeusz Bak)
  Re: in2000-SCSI drivers crashed when using HD intensively (Larry Doolittle)
  [CAP} Thought I read a post... (Eric Brunson)
  Diamond Stealth 32 (WEF Solutions)
  Re: IDE Performance Package Release? (Was Re: IDE PERF. PATCH SECURITY) (Mark Lord)
  Re: AF_UNIX SOCK_STREAM broken even in kernel 1.1.13. (Alan Cox)
  Re: Pascal compiler for L (John Will)
  Re: 'meta data' - the old fashioned way (Mark Evans)
  PCI Motherboards & Cards (kch)
  Re: getting a value from a port using inb() (Paul Tomblin)
  Re: IDE PERF. PATCH SECURITY HOLE (Mark Lord)

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

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: Wed, 15 Jun 1994 02:45:17 GMT

In article <2tkt49$586@news.iastate.edu>,
John Hascall <john@iastate.edu> wrote:
>   I suppose one could have a system where a disk had 2 free
>   lists, 1 zerod, 1 not.  Blocks could only come from the
>   zerod list, and the system could zero blocks in idle time
>   (moving them from one list to the other).
>

a file corrupted with zeros is still corrupted ... not a security
risk unless the file is critical to use of a system and causes
another form of fault that exposes you.

The point is that file corruption, in particular undetectable
file corrupt is not necessary.

John

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

From: lellis@dmccorp.com (John Lellis)
Crossposted-To: comp.os.linux.admin,comp.os.linux.help,comp.os.linux.misc
Subject: Re: Pascal compiler for Linux?
Date: 15 Jun 1994 15:45:31 GMT

Hans Vermeulen (vermeule@wi.leidenuniv.nl) wrote:
: Hello,

: I am looking for a Pascal compiler for Linux.
: Is there one out there? I don't like to use a pascal-to-c translator and gcc.
: So, anybody got a clue? After all, there is modula-2/3, eiffel, fortran, ....,
: so why no pascal?

Where can one get GNU PASCAL?  GNU FORTRAN?  Not p2c or f2c, but the real thing?

--

John Lellis (lellis@dmccorp.com)

--
... Our continuing mission: To seek out knowledge of C, to explore
strange UNIX commands, and to boldly code where no one has man page 4.




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

From: whistler@ius.gun.de (Karl Mueller)
Subject: Dialer wanted
Date: 13 Jun 94 00:00:00 GMT

Hello,

is there a Linux-Dialer like (tlo/bluebeep) avail for Linux ?

thanks Karl



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

From: pietro@myhost.subdomain.domain (pietro)
Subject: Dialogic drivers
Reply-To: dan@dialsun.ece.arizona.edu
Date: Wed, 15 Jun 94 08:59:33 GMT

I have a couple of dialogic 4 line telefony cards that I have dos drivers
and C libraries for. Has anyone hacked at these, know the I/O addresses or
anything about them. I would like to get some drivers for linux so I can
write some applications under linux for them. Those include, automated
answer/response systems, 1900 systems etc....

--
Pietro @ Bitstream Technologies, Inc.
Linux!

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

From: fred@vt.edu (Fred Homan)
Subject: IDE Performance Package Release? (Was Re: IDE PERF. PATCH SECURITY)
Date: 15 Jun 1994 16:09:33 GMT

Mark Lord (mlord@bnr.ca) wrote:
: No big deal.  I'll add some paranoia (aka kernel bloat) to the next revision
: of the IDE Performance Package..

        Say, Mark, when can we expect to see the next version come out?  I
just installed the last one and was looking for some runtime way of keeping up
with current operating performance rather than having to run a timing script
whenever I want to know...  Could be a useful feature if it's not too much
trouble.

---
Fred Op

************************************************************************
+ fred@vt.edu   fred@polaris.async.vt.edu       homanf@vtvm1.cc.vt.edu +
+----------------------------------------------------------------------+
+  Fred Homan, PO Box 232, Blacksburg, VA 24063-0232   (703) 231-3722  +
+----------------------------------------------------------------------+
+                "Mistletoe can be deadly if you eat it..."            +
+            "But, a kiss can be even deadlier if you mean it."        +
************************************************************************

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

From: ajs@spareme.engr.sgi.com (Adam Sweeney)
Crossposted-To: comp.benchmarks,comp.sys.sun.admin,comp.security.unix
Subject: Re: Filesystem semantics protecting meta data ... and users data
Date: 15 Jun 1994 15:29:49 GMT

>a file corrupted with zeros is still corrupted ... not a security
>risk unless the file is critical to use of a system and causes
>another form of fault that exposes you.
>
>The point is that file corruption, in particular undetectable
>file corrupt is not necessary.
>
>John

John,

So far your proposal seems to have been to order all writes
to file data before any of the meta-data writes which will make
that data permanent.  While that will probably work for newly
written files, it doesn't do much for the consistency of
multi-block updates to an existing file unless you go to a
no-overwrite scheme and commit all of meta-data atomically.

It seems to me that what you want is transactional file update,
where both the meta-data and the data are protected by the
transaction.  Is that accurate?  I think this would be very
useful functionality for the examples you've given, i.e. mail
files, log files, password files.  I wouldn't go so far as
to say that all file updates require such strict behavior.

For example, we had a customer here at SGI who was very upset
that EFS would eat their 300 MB log file when they crashed.
Well, it at their file because EFS was using a scheme very
similar to what you've been proposing.  The inode would not
go to disk until all of the data in the file had.  Since they
never stopped writing the file long enough for this to happen
the inode never went to disk.  We've changed the behavior of
EFS now so that the parts of the file which have made it to
disk become permanent, but this is just an example of how
your all or nothing argument does not satisfy everyone.

In my opinion, what would be really nice would be multfile
transactional file update.  Of course, this requires a
concurrency control mechanism and all that, but it would
be handy.  What I see at work, however, is that customers
are not asking for this.  They want huge files with huge
data rates to and from the files.  They want huge file systems
that don't take days to bring back online.  Nobody asks
for perfect data consistency semantics.

Oh well, maybe someday.

Adam Sweeney
MTS
Media Systems Division
Silicon Graphics, Inc.






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

From: entropy@world.std.com (Lawrence Foard)
Subject: Re: AF_UNIX SOCK_STREAM not reliable under Linux!
Date: Wed, 15 Jun 1994 19:12:07 GMT

In article <GTHAKER.94Jun11190016@polyphony.sw.stratus.com>,
Gautam Thaker <gthaker@polyphony.sw.stratus.com> wrote:
>
>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.

Try sending less than 4096 down, I think your running into a buffer problem.
If you send 4096 downyou will get 4095 on the first read and 1 on the next
read. As far as I know there is nothing which says a read will give you the
same number of bytes as the write on the other end.
-- 
====== 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: Re: AF_UNIX SOCK_STREAM broken even in kernel 1.1.13.
Date: 15 Jun 1994 17:54:10 GMT

In article <GTHAKER.94Jun14124008@polyphony.sw.stratus.com> gthaker@polyphony.sw.stratus.com (Gautam Thaker) writes:
>
>>A while back I posted that 0.99p15 had broken AF_UNIX 
>>SOCK_STREAM support. Someone suggested this has been fixed
>>in V1.1 series kernels. I picked up V1.1.13 and this version
>>too has this broken. ANyone know when NET3 is to come out?
>>A comment in unix.c file suggests this might be fixed in NET3.
>
>It'll get fixed once the big restructuring jobs are done. There's nothing much
>wrong with SOCK_STREAM barring a lack of ioctl() support and the fact that
>a write of >4095 bytes gives you a return of 4095 and writes 4095 bytes
>which is in fact technically reasonably correct.

>Alan

Well, I have also been testing V1.1.13 kernel with AF_UNIX 
SOCK_STREAM writes of 2048 bytes. I do a series of 100 of them
one after another and received reads them out as fast as it can.

I often get (1) corrupted data at the other end...(2) not as
many bytes out as I write. But Alan is prob. correct; I am not
looking at return value from "write" call.

Will this have to wait till full NET 3 or will this be patched
sooner? 

Will SOCK_DGRAM be supported fully for AF_UNIX?

Gautam


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

From: dmw@prism1.prism1.com (David Wright)
Subject: Re: IDE PERF. PATCH SECURITY HOLE
Date: Wed, 15 Jun 1994 11:57:10 GMT

>>>>> "FL" == Frank Lofaro <ftlofaro@unlv.edu> writes:

  FL> The IDE performance patch has a serious security hole!  ANY USER can
  FL> set the multiple mode and irq unmasking if they have access to the
  FL> drive. Even if it is ONLY READ-ONLY access to one partition.

        What about making the program mode 500 and owned by root?

                                                        Dave
--
  ____________________________________________________________________________
 |        /\ /          | Prism Computer Applications        |  David Wright  |
 |      -/--\--         | 14650 Detroit Ave, Suite LL40      | dmw@Prism1.COM |
 |      /____\          | Lakewood, OH 44107  USA            |  216-228-1400  |

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

From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: assembly language & Linux (ATTN!)
Date: Wed, 15 Jun 1994 16:00:45 GMT

In article <2tmpm0$ejg@klaava.helsinki.fi>, torvalds@cc.Helsinki.FI (Linus Torvalds) says:
+---------------
| 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. 
| The Alpha is much more different from the i386 than the 68k stuff is, so
| it's likely to get most of the stuff fixed. 
+------------->8

...but the 680x0 port will still be the one that finds the endian bugs, of
course :-)

++Brandon
-- 
Brandon S. Allbery         kf8nh@kf8nh.ampr.org          bsa@kf8nh.wariat.org
Friends don't let friends load Windows NT.

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

Crossposted-To: comp.os.linux.admin,comp.os.linux.help,comp.os.linux.misc
From: gcbak@cyf-kr.edu.pl (Tadeusz Bak)
Subject: Re: Pascal compiler for Linux?
Date: Wed, 15 Jun 1994 18:35:34 GMT

In <2tk7a7$jbl@nic.wi.leidenuniv.nl> vermeule@wi.leidenuniv.nl (Hans Vermeulen) writes:

>Hello,

>I am looking for a Pascal compiler for Linux.
>Is there one out there? I don't like to use a pascal-to-c translator and gcc.

There is a GNU Pascal Compiler GPC 2.5.7 in the Debian package.

--
  Tadeusz
  Cracow, Poland


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

From: doolitt@myhost.subdomain.domain (Larry Doolittle)
Subject: Re: in2000-SCSI drivers crashed when using HD intensively
Date: Wed, 15 Jun 1994 15:13:50 GMT

Charles E Meier (cemeier@magnus.acs.ohio-state.edu) wrote:
: 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. 

: 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.

If you want a reliable IN2000 driver, use version 0.3 on sunsite.unc.edu.
If you want a fast IN2000 driver, use the "new" version from Bill Earnest
on tsx-11.mit.edu.  If you want one that is both fast and reliable, start
from Bill's and debug it.  I haven't had time to start that yet.

                  - Larry Doolittle   doolittle@cebaf.gov

P.S. Apologies for errors in the header - I just changed newsreaders
and haven't chased down all the config issues yet.

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

From: brunson@sun1.SCRI.FSU.EDU (Eric Brunson)
Subject: [CAP} Thought I read a post...
Date: 15 Jun 94 11:27:39


Did I read a post a few weeks ago that someone was working on getting
native ethertalk to run inder linux?  I've compilied the current
release with the linux patches and everything runs well, but I'm about
to have to give up my fastpath, and that will mean IPTalk will stop
being useful to me.

Anyway, if someone is working on it, I'll volunteer help otherwise,
I'll look into the port myself.

e.


--
===========================================================================
Eric Brunson                                           brunson@scri.fsu.edu
Unix System Manager / CM2 Manager                              904.644.0188
Supercomputer Computations Research Institute      Florida State University

When I make my first million, I think I'll buy myself some happiness;
If there's a sale on satisfaction, I might just have to stock up.
                                                           -Human Radio

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

From: wef@netcom.com (WEF Solutions)
Subject: Diamond Stealth 32
Date: Wed, 15 Jun 1994 16:11:47 GMT

I would like to know if anyone has written a driver for the Diamond Stealth 32 card.  I have spent the last three weeks tring to get help from Diamond on getting X-windows to work.  Finial last night, they told me the only way to get it to  work was to write a driver and I might find help on the Internet.

I am new to Linux, Unix, and X-windows.  I do not know how to write a driver.  If anyone can help, please mail me at wef@netcom.com.  Any help would be greate. 
I have signed a Non-disclosure agreement with Diamond, so I can get there
proprietary information.

Thanks for any help
-- 
                                             wef@netcom.com

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

From: mlord@bnr.ca (Mark Lord)
Subject: Re: IDE Performance Package Release? (Was Re: IDE PERF. PATCH SECURITY)
Date: 15 Jun 1994 19:23:03 GMT

In article <2tn93t$6ug@solaris.cc.vt.edu> fred@vt.edu writes:
..
>       Say, Mark, when can we expect to see the next version come out?  I

Real Soon Now.  :)   Maybe this month.

>just installed the last one and was looking for some runtime way of keeping up
>with current operating performance rather than having to run a timing script
>whenever I want to know...  Could be a useful feature if it's not too much
>trouble.

I'll give it some thought..  The idea is to do as much as possible outside
of the kernel for "extras" like this.

In any event, such enhancements are unlikely to surface unless/until this
code makes it into the stock kernel (turned off by default for universal
compatibility, as on the LGX cdrom).  Then it would be easy for anyone to
do nifty add-on things for it.
-- 
mlord@bnr.ca    Mark Lord       BNR Ottawa,Canada       613-763-7482

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

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: AF_UNIX SOCK_STREAM broken even in kernel 1.1.13.
Date: Wed, 15 Jun 1994 16:17:09 GMT

In article <GTHAKER.94Jun14124008@polyphony.sw.stratus.com> gthaker@polyphony.sw.stratus.com (Gautam Thaker) writes:
>
>A while back I posted that 0.99p15 had broken AF_UNIX 
>SOCK_STREAM support. Someone suggested this has been fixed
>in V1.1 series kernels. I picked up V1.1.13 and this version
>too has this broken. ANyone know when NET3 is to come out?
>A comment in unix.c file suggests this might be fixed in NET3.
>
It'll get fixed once the big restructuring jobs are done. There's nothing much
wrong with SOCK_STREAM barring a lack of ioctl() support and the fact that
a write of >4095 bytes gives you a return of 4095 and writes 4095 bytes
which is in fact technically reasonably correct.

Alan



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

Subject: Re: Pascal compiler for L
From: john.will@dscmail.com (John Will)
Date: Wed, 15 Jun 94 16:57:00 -0640

T >I don't believe GNU Fortran is yet available,
T >though it has been under development for some years.

As simple as Fortran is, it's kinda' amazing it takes years. ;-)

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

From: evansmp@mb5194.aston.ac.uk (Mark Evans)
Subject: Re: 'meta data' - the old fashioned way
Date: Wed, 15 Jun 1994 19:48:25 GMT

Dirk-Jan Koopman (djk@dirku.demon.co.uk) wrote:
: Many (many) years ago there was a (wonderful) operating system called George 3
: (yes I was one of those programmers!). The way directory updates were done was
: as follows:-

: The result was a fast, very resiliant, filesystem very similar in form to a
: unix file system (with directories etc etc).

If I remember my Operating systems design correctly George cannot have both
files and sub directories in the same directory.

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

From: kch@edgtech.demon.co.uk (kch)
Subject: PCI Motherboards & Cards
Date: Wed, 15 Jun 1994 19:28:52 +0000

Has Linux been run on PCI motherboards?

I am looking at getting an Intel 60Mhz Pentium PCI board and need to know if
Linux works on it before purchase.

Additional cards are ATI Mach 32 PCI video card and a PCI single chip SCSI
controller (NEC I think). Will these work?


--
,---------------------------+----------------------------------------------.
| Keith Howell              | EdgTech International Ltd, 4/5 North Bar St, |
| kch@edgtech.demon.co.uk   | Banbury, OX16 0TB, United Kingdom.           |
| kch@cix.compulink.co.uk   | Tel +44 (0)295 277088 Fax +44 (0)295 279179  |
`---------------------------+----------------------------------------------'

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

From: pt@gandalf.ca (Paul Tomblin)
Subject: Re: getting a value from a port using inb()
Date: 15 Jun 1994 13:06:34 -0400
Reply-To: ptomblin@gandalf.ca

rickp@newton.physics.mun.ca (Rick Power C-3028 x-8844) writes:

>------------------------------beginning of C program-----------------------
>#include<stdio.h>
>#include<asm/system.h>
>#include<asm/io.h>
>main()
>   {
>   unsigned int PORT_ADDRESS;
>   unsigned int PORT_VALUE;

>   PORT_ADDRESS = 0x300;
>   PORT_VALUE = inb(PORT_ADDRESS);

>   printf("PORT address %d contains value %d \n", PORT_ADDRESS, PORT_VALUE );

>   }
>------------------------------end of C program-----------------------------

>how I compile:

>rupert:~> gcc thefileabove.c -o port_listen

>somewhere along the way of compilation the C compiler says :

>/tmp/cca013471.o: Undefined symbol ___inbc referenced from text segment
>/tmp/cca013471.o: Undefined symbol ___inb referenced from text segment

I had the same problem - and I couldn't find outb and inb defined in any
library, either.

So I faked it, and replaced the inb call with:
           __asm__  __volatile__   ("in%B0 %1,%0":"=a"(data):"d"(port));

Of course, you also have to remember to do an ioperm() call before you
attempt this, and run as root.

-- 
Paul Tomblin, Head - Automation Design Group.
Gandalf Canada Limited
This is not an official statement of Gandalf, or of Vicki Robinson.
"Hello, this is Linus Torvalds, and I pronounce Linux as Linux"

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

From: mlord@bnr.ca (Mark Lord)
Subject: Re: IDE PERF. PATCH SECURITY HOLE
Date: 15 Jun 1994 13:33:56 GMT

In article <1994Jun14.175359.29203@unlv.edu> ftlofaro@unlv.edu writes:
..
>Also look at my other post where I suggest a reason for giving a user read 
>only access to just ONE partition. hdparm /dev/hda2 will work if you 
>have read-only access to /dev/hda2. It affects the whole drive, of course.

No big deal.  I'll add some paranoia (aka kernel bloat) to the next revision
of the IDE Performance Package..
-- 
mlord@bnr.ca    Mark Lord       BNR Ottawa,Canada       613-763-7482

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


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