Subject: Linux-Development Digest #746
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:     Sun, 22 May 94 03:13:14 EDT

Linux-Development Digest #746, Volume #1         Sun, 22 May 94 03:13:14 EDT

Contents:
  Re: Two suggestions that might speed up Linux. (Michael P. Lepore)
  Will Linux ever support BSDstyle UNIX DOMAIN SOCKETS ? (Frank Luthe)
  SIGHUP: We tried it! (Sean Puckett)
  Re: PCI or VL bus SCSI Host Adapters (Scott Ferris)
  Re: Anybody working on BSD dump porting? (Barry Lynam)
  Re: Anybody working on BSD dump porting? (David Barr)
  Re: SIGHUP - Deep Kernal Guts question! (las@light-house.uucp)
  DPT SmartCache EISA Drivers (Scott Drassinower)
  Re: Linux Intrntl & Auto Cfg project (C. S. Hendrix)
  SYS HANG ON BOOT TIME ... HELP ! (Your Listener)
  Re: Nfs Buffercache Brok (Robert Andrew Ryan)
  Re: Appletalk support? (David Hornsby)
  Bug in Mitsumi CDROM driver (jvs@netcom.com)

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

From: leppa@bigwpi.WPI.EDU (Michael P. Lepore)
Subject: Re: Two suggestions that might speed up Linux.
Date: 22 May 1994 01:43:56 GMT

In article <klausf.769178506@toklotum>,
Klaus Frank <klausf@toklotum.informatik.rwth-aachen.de> wrote:
>wos@dcs.warwick.ac.uk (William O Smith) writes:
>
>>Suggestion 1:  Compressed buffers.  On fast machines, if there is idle
>>         time, and spare buffer space, how about compressing the
>...swap-partition...
>
>If you feel strange, you could start compressing those swap-pages which 
>consist of 95% zeros (just browse your swap-partition with bpe). You
>could use a simple run-length encoding scheme to start experiments.
>
Couldn't you use the Beta-patch double-0.2?

I remember starting to use this and it made devices that the space was
compressed on, couldn't you use those for compression?



-- 
Things are not  |    "I refuse to engage in     | leppa@wpi.wpi.edu 
always as they  |     a battle of wits with     |      CS '97       
  appear...     |     an unarmed person..."     |


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

From: fl@Germany.EU.net (Frank Luthe)
Subject: Will Linux ever support BSDstyle UNIX DOMAIN SOCKETS ?
Date: 20 May 1994 10:21:11 +0200


Hi developers,

is it planed? Is somebody working on it?

-- 
           Frank Luthe

  ===    ____                          ===       fl@Germany.EU.net 
  ===   /      /   /   ___    ___  _/_ ===       EUnet Deutschland GmbH
  ===  /----  /   /  /   /  /___/  /   ===       Emil-Figge-Str. 80
  === /____  /___/  /   /  /___   /    ===       D-44227 Dortmund 
  =====                              =====       Tel. +49 231 972 2222
  ===== Connecting Europe since 1982 =====       Fax  +49 231 972 1111

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

From: nate@loreli.ftl.fl.us (Sean Puckett)
Subject: SIGHUP: We tried it!
Date: Fri, 20 May 1994 15:17:24 GMT


Okay.  I hacked the kernel, just like this:

In kernel/exit.c
  copy routine kill_sl making a new routine called kill_sess.
  remove the second test from the if statement in kill_sess that selects
     only leader processes.

In include/linux/kernel.h
  add a prototype for kill_sess that matches kill_sl

In drivers/char/tty_io.c
  change two calls to kill_sl to kill_sess


This solved many of our test cases, but also screwed up another program which
hadn't detached itself from the terminal and was simply ignoring stdin as
its way of staying alive through loss of tty.

So, sadly, we changed it back.  I figure, if we're going to have to hack
out a way to solve the problem, we should hack from the point of an unblemished
kernel, rather than a blemished one.  Then our work will be useful to others
in similar circumstances.

Perhaps this is an 'i told you so' from the ivory tower tribe.  Like I said,
being right isn't what matters to me.  Finding a solution to my problems is.

Still taking suggestions!


--
                       ..:: nate@loreli.ftl.fl.us ::..
             ..:: Sean Puckett - Albino Frog Software, Inc. ::..
          ..:: The Right Reverend Aural Hardly, MSK, BoC, FCoC ::..

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

From: sferris@math.macalstr.edu (Scott Ferris)
Crossposted-To: comp.os.linux.misc
Subject: Re: PCI or VL bus SCSI Host Adapters
Date: 22 May 1994 01:42:56 GMT

Bill Heiser (heiser@world.std.com) wrote:
> Neither the hardware FAQ nor the kernel config stuff mentions
> anything about support in LINUX for VL or PCI bus disk controllers.
> I'm particularly concerned about ADAPTEC support.

> Are there any plans to support these so we can use the
> faster busses for SCSI support?

  The Adaptec 6360 chip is used by some VL boards, which is supported
(somewhat anyway) by the Adaptec 1520 driver.  Last I heard there
were some timing problems, but they may have been resolved, I haven't
been following that too closely.

  I'm working on a driver for the aic-7770 chip, which is used in
the EISA 274x, VL-BUS 284x, and (when released, if they aren't yet) 
PCI 294x boards.  I'm hoping to have an alpha ready by the end of the 
summer.

  At the moment I only have an old 2742T myself.  I can't directly
test the 284x models, because I don't have one (anyone want to donate
a new 2840AT? ), and I can't test the PCI one since I don't have access
to any PCI machines.  Still, if the driver works for one bus, it should
work for all of them, and I have people with 274x and 284x volunteering
to test the driver.  


--
Scott M. Ferris,             sferris@math.macalstr.edu
LaserMaster Inc,
Macalester College,
and points in between.


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

Crossposted-To: comp.os.linux.help
From: lynam@qut.edu.au (Barry Lynam)
Subject: Re: Anybody working on BSD dump porting?
Reply-To: B.Lynam@qut.edu.au
Date: Fri, 20 May 94 04:05:04 GMT

In article <2rdcfn$lu4@csugrad.cs.vt.edu>, mmead@csugrad.cs.vt.edu
(matthew "pipeman" mead) writes:
|> In article <CpyxL3.AzH@pe1chl.ampr.org>, Rob Janssen <pe1chl@rabo.nl>
|> wrote:
|> >Because of the many filesystems that Linux supports, trying to port
|> >something like "dump" is not simple, and IMHO not a good idea.
|> >
|> >You are better off making backups with "tar" or "cpio".
|> 
|>      What if you need to backup over the net?  There's rdump, but I
|> assume
|> that won't work for the same reasons that dump won't ... how would
|> dumping to a
|> disk mounted on a machine elsewhere on your local net be
|> accomplished? :-)

GNU Tar can do that. I have tested it. Needs to be setup on the machine with
the tape the same as rdump. Just put the file as machine:/dev/tape.


+------------------------------------------------------------------+
| Barry Lynam                           EMail:  B.Lynam@qut.edu.au |
| Communications - Network Services     Phone:  +61 7 864 2883     |
| Computing Services                    Fax:    +61 7 864 1343     |
| Queensland University of Technology   Postal: GPO Box 2434       |
| Brisbane AUSTRALIA                            Brisbane 4001      |
|                                               AUSTRALIA          |
|--"I may not agree with your argument, but I'll defend your ------|
+---right to express it"-------------------------------------------+


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

From: barr@pop.psu.edu (David Barr)
Crossposted-To: comp.os.linux.help
Subject: Re: Anybody working on BSD dump porting?
Date: 20 May 1994 00:20:07 -0400

In article <2rh32n$7fu@apollo.west.oic.com>,
Matthew Dillon <dillon@apollo.west.oic.com> wrote:
>:1. Does multiple dump levels
>
>    so does gnu tar (script enclosed).

Not quite the same thing.  (gawd, writing scripts in tcsh? be serious!)
You should use the level-0 and level-1 scripts that come with GNU tar.
(I do - I back up a 4+GB filesystem with it)

>:2. Handles sparse files (and handles them correctly)
>
>    gnu tar does this to a degree (it can detect that a file

Like I said, it does them correctly.  (Not the way GNU tar does it)

>:3. Handles hard links (and handles them completely)
>
>    What do you mean by completely?  tar handles hard links,
>    but I may be missing something here.

Tar has limits on the number of hard links it will keep track of.
(it's a low number, around 128?)

>:6. No pathname length/filename restrictions
>
>    neither with gnu tar, though it's decidedly a hack.

Exactly.  Backwards compatibility.

>    [r]dump has many disadvantages:
>
>    * you are at the mercy of the [r]dump program when part of the backup
>      is corrupted.

And you're not with tar?  (forgetting Emacs's tar-mode)

>    * dumps are not portable across architectures or filesystems.

False.

--Dave
-- 
"WAIS is the Pinto of the Information Superhighway" - me

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

From: las@light-house.uucp
Subject: Re: SIGHUP - Deep Kernal Guts question!
Date: Fri, 20 May 1994 18:11:26 GMT
Reply-To: whome!light-house!las@planix.com

Alan Cox (iiitac@uk.ac.swan.pyr) wrote:

I am sorry to post this but I have no other way of contacting you Ian.

Could you please use a valid reply adress in your posts?

Your site "uk.ac.swan.pyr" is not in the DNS, and many times my replies
to you have bounced. 

It is frustrating not being able to contact an important kernel developer
as yourself.

    Regards,
    
 Laszlo
 

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

From: scottd@cloud9.net (Scott Drassinower)
Subject: DPT SmartCache EISA Drivers
Date: 22 May 1994 00:13:27 -0400


        Is there any word yet on drivers for the DPT SmartCache EISA 
controllers?  Specifically, I have a 2022/95 in a system that I would 
like to get Linux setup on.  I remember hearing some discussion about 
these drivers being developed, but have not heard anything for the past 
2-3 months.

        Do these drivers exist?  Are they being worked on?  Will they 
ever be available?

-- 
 Scott Drassinower * scottd@cloud9.net 
 Cloud 9 Internet  * White Plains, New York 

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

From: shendrix@escape.widomaker.com (C. S. Hendrix)
Subject: Re: Linux Intrntl & Auto Cfg project
Date: Sat, 21 May 1994 15:34:04 GMT

CHRISTOPHER M MAY (cmay@titan.ucs.umass.edu) wrote:

: IMHO:
: Linux isn't for the feint of heart when it comes to computer knowledge.
: It's really for those who want to push the envelope of what their PC
: can do, under a multitasking Unix-like OS.

What about people who just need one?  A lot of people use Linux as
their main OS and love it.  They aren't hackers and benefit from
good distributions.

: Do we really want people who can't tell a jumper from a gender-mender
: using this OS?  Can they possibly contribute to it's progress?

Since when was it necessary for someone to contribute in order to use
something?  Besides, they contribute just by using it.  If only the
people you suggest as the ones who should be using Linux used it, it
would not be where it is today.

: It sounds to me like a big effort to sell some people (i.e. newbies)
: something they don't really want, by hiding some of the complexity of 
: the system from them.

You just described the Mac!  :-)  Really, what is wrong with this?  I
certainly have no problem with current distributions but why should I
waste my time having to screw around with it all the time?  Why can't I
just let it install itself?  I rather spend more time using it and
programming, not constant maintenance.  Even the most egotistical hacker
eventually gets tired of showing off how good he is.  Ease and
automation of tedius tasks is good for EVERYONE.

: Can't people just work on drivers and real hardware support, and leave
: the distributions as they are?

Sure.  But I'm glad they didn't becuase Linux would not be worth a damn
if they hadn't.  I don't have time to build my own distribution and go
through the pure hell required to keep various versions of the packages
working together.

As far as Linux International goes... I still don't know what they
are supposed to be.  But man would I ever love to see Linux get
easier to install.  I want to spend my time programming, not installing
UNIX.

: --

: -Chris May, Computer Science, University of MA, Amherst
: -     Technical Assistant, P.C. Maintenance Lab

-- 
csh
===========================================================================
shendrix@escape.widomaker.com (UUCP)     | Amd486/40 Linux system
shendrix@pcs.cnu.edu (Internet)          | Christopher Newport University

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

From: ez030933@othello.ucdavis.edu (Your Listener)
Subject: SYS HANG ON BOOT TIME ... HELP !
Date: Sun, 22 May 1994 04:58:07 GMT


Hi to all Linux expert,

        Thanks for all the help on re-compiling the kernel and make my
BUS mouse works ..... Yes, I got X win running .... However, just for
an Hour. WHy ???? After I reboot ... , I cannot even mount the root ...
I think the ext2 file sys. is very buggy in this stage and the new version
and old version of mk2sck and e2fsck are all conflicting each other ....
I try to reboot with BARE ( BOOT ) disk then color144 ,,,, I mount my 
hard disk partition /dev/hdb1 ( the first partition of 2nd hard drive ) 
manually and run e2fsck -pf to fix the prob. .... ( automatically fixed )
Yuh, it said it fixed the file sys and then I reboot again with my custom
boot disk .... it won't work again 
all I can go is to this stage :

VFS mount ext2 /dev/hdb1........ 

the sys then hang like stoned .... I wait for 10 mins. still nothing done

Then I try again with just booting with BARE disk with parameter like

boot: mount root=/dev/hdb1 


and happens the same thing - hanging system ....

I install this version ( slackware 1.20 ) closed to 10 times .... and it 

just works for a while and then tell me my fs messed up and cannot log in ...

I also use the new fdisk 1.5a to repartition the hard disk but even worse like

something NULL buffer pointer inode something ..... kernel panic ..... and all

kinds of trouble .....   


I also getting message like "swap-free wierdness" "trying to free nonexistent
swap pages" "swap table [21849e99] bad " and all those crazy error message ...

I noticed one thing .... all those message will go if X win is running instead
of the console prompt mode .... WHy ??????

I am tired as heck of this new slackware version .... if nobody can help me 

I am going back to my old version of SLS 0.99 ( luckily I still keep my disks )

since it works fine and no such stupid fs check at boot up which make me cannot

even log in or the stupid e2fsck even trash my fs.....

Thanks in advance ....

=}



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

From: Robert Andrew Ryan <rr2b+@andrew.cmu.edu>
Subject: Re: Nfs Buffercache Brok
Date: Fri, 20 May 1994 01:28:30 -0400

I don't substatially disagree with any of the statements in the last
reply, but I think they deserve clarification.

Excerpts from netnews.comp.os.linux.development: 18-May-94 Re: Nfs
Buffercache Brok Russell Coker@f363.n633. (1490)

>  AFS will give much better performance for WANs, at the cost of
> reliability.  If the data is changed often/at all then there are huge
> consistency problems. 

AFS is actually used at CMU for a system where the data changes ALL the
time.  Incoming news is placed in AMS (Andrew Message System) folders on
AFS.  The  AMS clients then read the messages from the directories on
AFS.  This is sub-optimal since while there are basically few writers,
there are many many readers so the servers with the central data (the
update list) tended to get swamped handling updates of the actual data
and informing clients of the change.  The key point about consistency is
that it is mostly a problem at the *file* level.  AFS is definitely not
good for a database where more than one machine will be updating a
single file.  (Using appropriate locking the file should remain
consistent, but the benefits of the cache are lost.)

Excerpts from netnews.comp.os.linux.development: 18-May-94 Re: Nfs
Buffercache Brok Russell Coker@f363.n633. (1490)

> Probably the best (only?) use of AFS is for
> mounting home directories, that way as long as a user is only logged
> in at one machine it will be usable.

In practice there is hardly ever a problem with a user accessing their
files from more than one machine at a time.

Excerpts from netnews.comp.os.linux.development: 18-May-94 Re: Nfs
Buffercache Brok Russell Coker@f363.n633. (1490)

> What AFS does to give good
> performance is to copy the entire file accross the network, let the
> local system work on it, and then copy it all back again.  This is
> obviously useless for database work....

Actually for some time now AFS has been able to do caching of parts of files.

For large file databases AFS loses on a number of points:

1. On some (all?) systems a file which is larger than the cache cannot
be written.

2.  On some systems not all the file locking functions are supported. 
(I think it was lockf that wasn't supported on the HP.)

3.  File 'holes' are backed with real disk space.

Excerpts from netnews.comp.os.linux.development: 18-May-94 Re: Nfs
Buffercache Brok Russell Coker@f363.n633. (1490)

> acg>What is the legal status of AFS?  Could a port to Linux be done

AFS is a product sold by Transarc Corporation.  They might provide
enough information to produce a free AFS client suite for Linux, but I
wouldn't hold my breath.

Excerpts from netnews.comp.os.linux.development: 18-May-94 Re: Nfs
Buffercache Brok Russell Coker@f363.n633. (1490)

>   However for a LAN situation I really don't think that AFS is a good
> thing as it causes more consistancy problems, requires large amounts
> of local drive space for buffering, and the Venus module would waste
kernel memory...

The local client cache size ranges from 10M to 100M or more.  It depends
on what size files need to be supported, and the amount of fetching over
the network which is acceptable.

As a user of AFS on the CMU campus since 1988, I can say it works quite
well in our environment.  (~5000 users, 100-200  machines, user accounts
and most application binaries on AFS, ethernet and 4M token-ring
networks)  Consistency isn't generally a problem, even when a single
user uses multiple machiines at once.

I believe the most productive thing to do would be to learn about AFS as
it exists today.  (Not the early design by a LONG shot, there used to be
a notion of servers for 'clusters' of workstations.)  Then design a new
system taking whatever concepts appear relevant from AFS and other
filesystem research.  If interoperability with AFS is an issue I believe
the simplest solution is to write a user-level server which runs on an
AFS client and exports AFS files with the new protocol.  (currently some
systems are capable of NFS exporting AFS, in particular IBM AIX 3.2.x)

-Rob

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

From: djh@cs.mu.OZ.AU (David Hornsby)
Subject: Re: Appletalk support?
Date: Fri, 20 May 1994 06:11:29 GMT

iiitac@uk.ac.swan.pyr (Alan Cox) writes:
>Linux can do this. Have a look at the BPF code in tcpdump. Thats a port of
>BPF for Linux in effect.

Both CAP and UAR already support BPF, this would be the easiest path towards
Linux support.

>Linux can send and receive 802.3 format packets happily. At the moment there
>are no set/clear multicast flags but if you want them added I'll put them
>in pronto!

Yes please. Multicast ability is needed for AppleTalk Phase 2.

 - David.

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

Crossposted-To: comp.os.linux.help
From: jvs@netcom.com
Subject: Bug in Mitsumi CDROM driver
Date: Fri, 20 May 1994 23:30:11 GMT

Hi, I have found a problem with the mitsumi driver in both the kernel
on the April InfoMagic CDROM and the v1.1.0 kernel on Sunsite.
On line 884 of mcd.c it calls irqaction(MCD_INTR_NR,  &mcd_sigaction)
It should be: irqaction(mcd_irq,  &mcd_sigaction)

The upshot is that the driver always trys to use irq 11, even if you
overide the irq on the lilo boot line.

This caused the aha152x driver to panic when it couldn't get the irq
so I couldn't install from the InfoMagic CDROM!

Oh well, back to making the floppy images!

Byee
Jo

-- 
========================================================================
Jo Stockley
jvs@netcom.com
jonathan@sybase.com

"Sausage time!" - Prince Regent in Black Adder III
========================================================================

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


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