Subject: Linux-Development Digest #856
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, 25 Jun 94 08:13:04 EDT

Linux-Development Digest #856, Volume #1         Sat, 25 Jun 94 08:13:04 EDT

Contents:
  Re: Major device number clash (iCS) (Gareth Newfield)
  1.1.18->1.1.21 new hd.c "feature" (S. Joel Katz)
  Setting TCP timeouts (Lewis Perin)
  Re: Strange stty/logout problem in 1.1.20 (Jonathan Magid)
  Re: Runtime compilation and execution (Donald Jeff Dionne)
  Re: proc/procps documentation? (Henry Ware)
  Re: Solaris x86 disk = 82 = Linux swap (Kjetil Torgrim Homme)
  Has anyone gotten the wretched All-in-one Ethernet adapter to work? (Ludwig Van.)
  Re: Porting libpthreads to Linux? (Harald Milz)
  Re: cp truncate some dos files, why? (Beverly J. Brown)
  IBCS2 and SVR4 (any experience present?) (lcvanveen@et.tudelft.nl)
  sunos fs ioctl for async metadata (Ed Pendzik)
  Re: Disk-compression for Linux (Phil Howard)
  Re: SIGCHLD not sent or ignored? (Rogon den Skjebnelause)
  Re: IDE PERF. PATCH SECURITY HOLE (Kevin Brown)
  Re: Hard disks limited to (John Will)
  Re: Linux ext2fs vs. ufs (John Will)
  Want ghostscript driver: cannon bj200e (I have bj200) + good ps fonts (Jason Venner)

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

From: gareth@metl.chi.il.us (Gareth Newfield)
Subject: Re: Major device number clash (iCS)
Date: 25 Jun 1994 02:10:27 GMT

Nick Holloway (Nick.Holloway@dcs.warwick.ac.uk) wrote:
: On the other hand, two separate files with _just_ the major information,
: and without the headings would be simpler to deal with.  If you want fancy

        IMHO this is a good idea, after all even though parsing the proc
file system is usually simple it does add up. Why parse a file when the
program knows what it needs and can ask for it directly? Instead of lots of
little programs needing duplicate parsing, you effectively just use the
file system code that is already there.

example just read:
 /proc/devices/character/thatSortofThing/someAttribute/something/this

instead of parsing
 /proc/deviceStuffIsAllJammedInHereTogetherWithWhoKnowsWhatDelimiters

btw I would like to see this approach taken with more of the proc filesystem.
for instance in version, stat, and the various net files. split them up.

gareth@metl.chi.il.us


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

From: stimpson@panix.com (S. Joel Katz)
Subject: 1.1.18->1.1.21 new hd.c "feature"
Date: 24 Jun 1994 02:11:01 -0400


        Howdy.

        I just upgraded from 1.1.18 to 1.1.21 and I get an interesting error
message during bootup:

============================

Partition check:
  sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 >
  sdb: sdb1 sdb2 sdb3
hd.c: ST-506 interface disk with more than 16 heads detected,
  probably due to non-standard sector translation. Giving up.
  (disk 0: cyl=21072, sect=57, head=186)
VFS: Mounted root (ext2 filesystem) readonly.

============================

        sda and sdb are my two SCSI drives connect to an aha1542. They are
the only hard drives in my system. I have no other hard drive controller and
my BIOS is set for no hard drives. Apparently hd.c thinks I have a weird
drive connected to a controller I don't have.

        (I believe at this point hd.c has not even looked at the hardware
yet and is only looking at the BIOS, but don't quote me on that)

        This isn't causing me any problems so it's not a big deal, but I
hate error messages and I prefer to keep standard hard drive support in my
kernel because I use the same kernel on two other machines that have IDE
drives.

        SJK


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

From: perin@mail.med.cornell.edu (Lewis Perin)
Subject: Setting TCP timeouts
Date: Wed, 22 Jun 1994 12:50:54 EST

The man page for getsockopt/setsockopt in the Linux version I use (kernel 
1.1.0, Yggdrasil Summer '94) lists options for TCP timeouts: SO_RCVTIMEO and 
SO_SNDTIMEO, both advertised as valid at the socket level (SOL_SOCKET.)  gcc 
unfortunately has never heard of them; they aren't to be found in 
linux/socket.h, and ip.c doesn't handle them.  (By the way, there's no trouble 
with a couple of other SO_xxx options.)  Can some kind savant help, e.g. by 
suggesting a more recent version of the kernel that will recognize these 
options, or some other way of achieving the same thing?

Thanks very much,

      __          perin@med.cornell.edu (212)746-2946
 |   |_  \    / : Lew Perin
 |__ |__  \/\/  : Home: (201)435-2679

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

From: jem@bittyblue.oit.unc.edu (Jonathan Magid)
Subject: Re: Strange stty/logout problem in 1.1.20
Date: 22 Jun 1994 04:26:26 GMT

In article <2u87u6$6p5@harbinger.cc.monash.edu.au>,
Kevin Lentin <kevinl@bruce.cs.monash.edu.au> wrote:
>
>With 1.1.20 suddenly, when I log in and my .login does an stty (it does 2,
>stty crt -ctlecho and stty erase ^?) the stty gets suspended (actually, I
>believe it's the .login being suspended) and I get a shell. If I 'fg' the
>suspended stty I get logged out.

Yeah- 1.1.20 changed some signal handling stuff- all the objects need to be
recompiled.


        make clean
        make zlilo

Should fix your problems. 

(Thanks to those who told me. :) )

jem.

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

From: jeff@ee.ryerson.ca (Donald Jeff Dionne)
Subject: Re: Runtime compilation and execution
Date: 25 Jun 1994 04:06:31 GMT

Steven Hugg (hugg@xi.cs.fsu.edu) wrote:
: Well, la-dee-daa!!! Looks like the data segment is executable after all.
                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^

Unless I misunderstand what I'm reading, The Design Of the UNIX Operating
System (Bach, Prentice Hall) says that should be a protection fault.....
In my interpretation, a segment fault.  Am I wrong, or does the 
memory management of the i386 not allow for detection of this?

: Just pop your code in and jump to it. Only problem is keeping the cache
: happy (didn't we just talk about this??). Isn't there an invalidate()
: function? Let me thread back and search for "cache"...

: Now all I have to do is figure out how to get GDB to let me disassemble
: code in the data segment :)

I don't think gdb has a disassembler..... gets it's source level debugging
info from the source and executable (I could be wrong about the disassembler
though).

: --
: Steven E. Hugg
: hugg@cs.fsu.edu

Jeff@EE.Ryerson.Ca

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

From: hware@bronze.coil.com (Henry Ware)
Subject: Re: proc/procps documentation?
Date: 25 Jun 1994 01:13:40 -0400

The proc/procps filesystem is documented in the LDP's Kernel Hacker's 
Guide.  Its at Sunsite, among other places.  

The particular code you want to look at is in the /usr/src/linux/fs/proc/ 
directory, particulary in the array.c file.  You will also find 
interesting code in the procps package.  

Cheers,
Henry
-- 
That does it!  I'm putting me back in my kill file!

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

From: kjetilho@ifi.uio.no (Kjetil Torgrim Homme)
Subject: Re: Solaris x86 disk = 82 = Linux swap
Date: 24 Jun 1994 16:25:56 GMT

+--- Rob Janssen:
| There is no real problem with this, as Linux is not checking the
| filesystem type, and you can put any value you like. Linux simply
| puts all active partitions in its in-memory table, so you can access
| them at will.
| 

I guess this means that Linux might as well migrate/discontinue its
numbers?


Kjetil T.

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

From: lruppert@iguana.syr.EDU (Ludwig Van.)
Subject: Has anyone gotten the wretched All-in-one Ethernet adapter to work?
Date: Tue, 21 Jun 1994 19:43:57 GMT


I bought an All-in-one ethernet adapter (NE2000 compatable, 10BaseT
and BNC ports).  The model number was the one ending in AC, 16 bit.
No matter what the setting is, the autodetect fails to find it, even
when I hardcode the IRQ and memory address.  I have another card I was
using, made by the same company, with the model number ending in UC,
and it worked fantastic.  My question is, does anyone else have this
model card working in their machine?  If so, how did you trick the
poor thing into working?  Are there any tips on coercing the stupid
thing into letting Linux 1.1.15 find it? (I tried earlier Linuxes too,
but to no avail.)

-Lou Ruppert
Flustered UNIX Weenie
-- 
"Until you stalk and overrun, you can't devour anyone."   -Hobbes
Lou Ruppert                     lruppert@mailbox.syr.edu
My opinions are my own.  My attention span isn't long enough for

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

From: hm@seneca.ix.de (Harald Milz)
Subject: Re: Porting libpthreads to Linux?
Date: Fri, 24 Jun 1994 15:08:59 GMT
Reply-To: hm@seneca.ix.de

John Romein (john@cs.vu.nl) wrote:

: > There is a pthread implementation for linux available from sipb.mit.edu
: > Due to the limited amount of anonymous ftp connections, it is hard to login.

Why then doesn't any kind soul put it "two doors" farther on tsx-11.mit.edu?
Theodore, would you ... ?

BTW: whoever initiated this thread: comp.os.linux.kernel is no valid 
newsgroup and never was. I deleted it from the header. 

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


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

From: bjb@shore.net (Beverly J. Brown)
Subject: Re: cp truncate some dos files, why?
Date: 22 Jun 1994 00:25:43 -0400
Reply-To: bjb@shore.net

In article <Crorz6.1DA@pe1chl.ampr.org>, Rob Janssen wrote:
> In <uiB1kukh1CZG066yn@shore.net> bjb@shore.net (Beverly J. Brown) writes:
> 
> >In article <1994Jun17.170538.27707@rosevax.rosemount.com>, Grant Edwards wrote:
> >> Romano Giannetti (romano@pimac2.iet.unipi.it) wrote:
> >> 
> >>   [file being truncated when cp'ed]
> >> 
> >> 
> >> Since PC-DOS (and MS-DOS) were "derived" from CP/M, and many of the
> >> early PC-DOS applications were ports of CP/M applications, the
> >> convention of using a ctrl-Z as an EOF marker persisted, even though
> >> PC-DOS (at least in 2.0 and later) keeps track of how long files are
> >> and will return EOF when you try to read past the last "real" data
> >> byte in the last block.
> >> 
> 
> 
> >Linux shoud NOT rely on CTRL-Z. It should do the right thing as DOS has 
> >since, as you pointed out, version 2.0.
> 
> This behaviour is caused by "conv=auto".  You won't believe how many DOS
> editors, even fairly recent ones, still append a ^Z at the end of the
> file :-(

I thought the text/binary modes referred to the CR/LF translation rather 
than CTRL-Z. It shouldn't truncate at CTRL-Z even for text files unless it 
is the last character in the file.

> 
> To get it right under Linux, just don't use "conv=auto".  It wasn't a
> good idea anyway.   (and I think it has got the direction of the pattern
> match wrong: everything it does not know to be binary it assumes to be text!)
> 

Yes, that does seem a little backwards. :)

Beverly J. Brown
bjb@shore.net
beverly@datacube.com

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

From: lcvanveen@et.tudelft.nl
Subject: IBCS2 and SVR4 (any experience present?)
Date: 21 Jun 94 21:32:16 +0200

I'm looking for someone with experience in using IBCS2
and the SVR4 libraries. What do I need apart from
the IBCS2 Alpha and SVR4libs.tgz, what trapfalls may
expect, etc., etc.
I want to test some SVR4 programs on Linux. This in
combination with DOS and Windows programs. Of course
anything interesting that comes out will be posted here.
Thanks a lot in advance for any help.
Martijn.

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

From: edp@pt.com (Ed Pendzik)
Subject: sunos fs ioctl for async metadata
Date: Sat, 25 Jun 1994 05:10:21 GMT

In the fs meta thread several people mention that they
used and ioctl on sunos filesystems which wrote metadata
in an async fashion.  

What is this ioctl? I dug through solaris 2.2 include files
(include/sys, include/fs) and didn't find anything except for a 
#define SYNC 1
#define ASYNC 0
(or something similar) in /usr/include/fs/ufs_<something>.h
[sorry so vague, I looked it up yesterday].

certain people mentioned the ioctl was in 4.x and 2.x.

Regards,
Ed Pendzik

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

From: phil@zeus.fasttax.com (Phil Howard)
Subject: Re: Disk-compression for Linux
Date: 21 Jun 1994 15:45:06 -0500

vinter@cs.uit.no (Brian Vinter) replies to what
kevin@valis.worldgate.edmonton.ab.ca (Kevin B. Fluet) writes:

>>I think  on-the-fly compression has been discussed by many people over the
>>last year, but nothing has come of it.  Basically, with hard drive prices
>>dropping dramatically every week (almost), it may not be worth the trouble. 
>>Prices are WELL under $1/MB these days.  Also, with the PROVEN unreliability
>                                                         ------
>>of compressed file systems, you would only have a few people willing to use
>>it.  

>What is this about compression is proved unreliable ? I have seen high school
>kids PROVE that compression is 100% reliable. It's really not that hard math
>to understand i.e. Huffmann compression. If what you're refering to is
>filesystem add-on's like Stacker and the rest of the MS-DOS and MAC world
>utilities, I'd claim that the unreliability comes from lack of compability
>with existing applications - not from the compression. So if the compression
>was included in the kernel it should be as reliable as any other FS. 

Well he did say "unreliability of compressed FILE SYSTEMS".  Hopefully he
knows that it is not the compression theory itself that is faulty.


>Your arguments for pricing of storrage has its points but there still are
>a lot of students and others for which every $ counts (like myself - teaching
>at University may be professionaly rewarding - but thats about the only 
>reward:). Also for CD-ROM's a compressed system would be an all win : 1.2 GB
>storage and improved transfer speed.

I don't really like seeing precise compression figures quoted.  Some of my
data gets whopping compression, but on average I've seen a good bit less
than 2:1 (usually around 1.75:1).


>Well the compressed FS idea has been floating around for quite a while -
>it shouldent be much of a problem to write a fragmented FS, lots of papers
>on that one. I think the main problem is to derive an efficient static
>compression protocol.

A probable area of unreliability of compressed file systems is the greater
level of complexity required to fragment the system in such a way that the
variability in size of compressed data does not cause so many gaps in the
data that the advantage of compression is lost.  If files were sequential,
you could compress them with an algorithm like zip and the compression state
would eventually be such that good ratios are obtainable.  In addition, the
compressed data itself can simply be broken up into pieces the size of the
filesystem's fragments and written sequentially.  Conventional allocation
would work.  In reality, many files need to be direct access.  Jumping to
the middle of a file means that it is necessary to process all of the data
from the last point of initial state (the beginning of the file is one such
point) to where the seek goes to.  If the only point of initial state is the
beginning of the file, then any backward seek has to start all over there.
The only way to avoid that is have many initial states in the file and lose
some ratio, or cache calculated states in the middle and eat RAM or SWAP.
The problem gets even worse when an update takes place.  Then the data
changes and the size of the compressed data for the remainder of the file
changes.  You either have to rewrite all of the remainder of the file, or
have some initial state points to stop at.  Even then the size up to such
points changes.

Compressed file systems can be done; that has been proven.  They also
involve a lot of detailed tradeoffs in the design.  The code is much
more complex and the compression algorithms themselves usually have to
be modified to deal with the particulars of the file system.  All of
this increases the exposure to design and implementation errors.

I'd rather see a filesystem that caches files up front from a back store,
but always present the appearance that all files are present.  The back
store might be compressed images of the files and perhaps even stored on
different media.  But then there is the delay time potentials and the need
for unblocked I/O, especially on mounted or networked media.
-- 
Phil Howard KA9WGN      | The drive spec says the capacity is 600mb unformatted
Unix/Internet/Sys Admin | and 525mb formatted.  So where do I find an unformat
CLR/Fast-Tax            | utility?
phil@fasttax.com        |

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

From: rogon@doom.tromsomh.no (Rogon den Skjebnelause)
Subject: Re: SIGCHLD not sent or ignored?
Date: Sat, 25 Jun 1994 10:46:28 GMT

In article <LEE.94Jun23163233@netspace.cis.brown.edu>, lee@netspace.cis.brown.edu (Lee J. Silverman) writes:
|> 
|>      I discovered the error.  By default, Linux follows the SysV
|> signal standards.  The first SIGCHLD was being caught by the parent,
|> but every subsequent signal was lost because the signal handler needed
|> to be reset.  Adding another call to signal after the wait3() call in
|> the signal handler did the trick.
|> 
|>      Mail me for details if you're interested.
|> 
|> Lee

For a techincal reason of this behavior. The reason is that the signal() system
call is automatically set with SA_ONESHOT | SA_NOMASK. This means that once a
signal is caught, subsequent signals are set back to default, which is SIGIGN,
ignoring the signal. 

If you do not want this behaviour use the sigaction() system call. 
We are working on proper docs and man pages on this matter.

|> 
|> --
|> Lee Silverman, Brown class of '94, Brown GeoPhysics ScM '95
|> Email to: Lee_Silverman@brown.edu
|> Phish-Net Archivist: phish-archives@phish.net
|> "Nonsense - you only say it's impossible because nobody's ever done it."

Sir Rogon.

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

From: kevin@frobozz.sccsi.com (Kevin Brown)
Subject: Re: IDE PERF. PATCH SECURITY HOLE
Date: Thu, 23 Jun 1994 13:34:50 GMT
Reply-To: kevin@frobozz.sccsi.com (Kevin Brown)

In article <2u1hpe$8us@geraldo.cc.utexas.edu>,
Dances With Geeks <lilo@slip-6-2.ots.utexas.edu> wrote:
>On 14 Jun 1994 08:41:38 +0200, Matthias Urlichs (urlichs@smurf.noris.de) wrote:
>
>> You misunderstood. If there's read-only access to _any_ partition, the user
>> can turn on the performance stuff, which will of course affect other
>> partitions on the same disk, presumably mounted R/W.
>
>But there's no REASON to allow ANYONE but root access to your disk
>partitions.

Sure there is.  For instance, I sometimes have to go into DOS
to do something (it's quite rare, though!), and I to have access to the DOS
partition when in Linux...via mtools, since often I just want to copy files
around without bothering with mount and unmount.  And then there's the DOS
emulator...

It would be silly (and potentially dangerous) for me to perform these
operations as root.

The provision for permissions on a user-by-user and group-by-group
basis are there because you can rarely, if ever, unequivocally say
that "there is no reason, ever, ever, ever, for anyone but root to
have access to X".

Of course, all of this is IMHO...
-- 
Kevin Brown                                     kevin@frobozz.sccsi.com
This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end >
            This is your .signature virus on drugs: <>
                        Any questions?

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

Subject: Re: Hard disks limited to
From: john.will@dscmail.com (John Will)
Date: Tue, 21 Jun 94 16:51:00 -0640

P > >There is a standard called "enhanced IDE" that should solve those
P > >problems.
P >
P >Yes.  No bullshit, no physical and logical geometry hassles, just
P >Linear Block Addressing (LBA).

Gee, why don't we call it SCSI? :-)

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

Subject: Re: Linux ext2fs vs. ufs
From: john.will@dscmail.com (John Will)
Date: Tue, 21 Jun 94 16:52:00 -0640

C >Then you could do as our sys admin did and trip over the power cord between
C >the ups and the computer. (sorry Glenn). :-)

Pretty stupid place for the power cord! :-)

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

From: jason@idiom.berkeley.ca.us (Jason Venner)
Subject: Want ghostscript driver: cannon bj200e (I have bj200) + good ps fonts
Date: 24 Jun 1994 18:54:13 GMT


I have a bj200e,  the bj200 driver works fine, but the e has some additional
grayscale features I would like to use.

Also, the postscript fonts with ghostscript are not the best. Does
anyone have good ones for distirbution or for sale ad a moderate
price?

Thanks -- Jason



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


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