Subject: Linux-Development Digest #775
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, 29 May 94 11:13:04 EDT

Linux-Development Digest #775, Volume #1         Sun, 29 May 94 11:13:04 EDT

Contents:
  Re: Absolute Disk Reads (Rob Janssen)
  Re: 32-bit Novell desktop OS combines Unix, DOS 7 (Mark Muhlestein)
  Re: InterLink for Linux (GLAUDE DAVID)
  Re: SIGHUP - Where do we go from here? (Leon Garde)
  Re: Kernel change summaries (David H Dennis)
  Re: Nfs Buffercache Brok (Lyle_Seaman@transarc.com)
  Re: SIGHUP - Where do we go from here? (Ken Pizzini)
  Re: PCI or VL bus SCSI Host Adapters (Graham Nicholls)
  Re: InterLink for Linux (Rob Janssen)
  Re: Appletalk support? (David Hornsby)
  Re: Routing requests and 1.1.15 (Thomas Roehl)
  Re: Zombie problems (Matthew Dillon)

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

Crossposted-To: alt.uu.comp.os.linux.questions,de.comp.os.linux
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Absolute Disk Reads
Reply-To: pe1chl@rabo.nl
Date: Sat, 28 May 1994 21:32:18 GMT

In <2s7f41$j7l@usenet.INS.CWRU.Edu> cs753@cleveland.Freenet.Edu (Erica Aleashia Ramsey) writes:


>Hello, I'm digging through linux kernel trying to learn how to do scsi
>and IDE programming; I want to write my own scsi/ide disk drivers. It
>will help me enormously if I knew how to do an absolute disk read in
>linux. That is, call some function with a sector number and instruct
>it to read the hd. Is there such a function in linux? I have gcc installed
>under linux. If I need a lib or function could someone please email
>it to me?

>I will appreciate it if I can get this posting answered right away because
>I have much time to work on it this weekend. I do data entry doing the week
>days and it's boring and tiring.

>PS: No, I don't have ftp! know where I can get it cheap in cleveland, Ohio?
>Netcom is very reasonable but they don't extend services to here. Ncoast and
>Wariat are pretty much out of my budget!

>thank you,
>Ms. Ramsey

try something like this:

#include <stdio.h>
#include <fcntl.h>

#define SECTORSIZE 512                  /* or whatever you like */
#define DEVICE  "/dev/hda1"             /* device you want to read */

FILE *rawdisk;
char buffer[SECTORSIZE];

initialization:

        if ((rawdisk = fopen(DEVICE,"r")) == NULL) {
                perror(DEVICE);
                exit(1);
        }


reading a sector:

        if (fseek(rawdisk,sector * SECTORSIZE,SEEK_SET) == EOF) {
                ... invalid sector ...
        }

        if (fread(buffer,SECTORSIZE,1,rawdisk) != 1) {
                ... read error ...
        }


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

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

From: mmm@park.uvsc.edu (Mark Muhlestein)
Subject: Re: 32-bit Novell desktop OS combines Unix, DOS 7
Date: Sat, 28 May 1994 22:49:18 GMT

In article <CqIAI5.3xs@pe1chl.ampr.org> pe1chl@rabo.nl writes:
>
>>It's already been done -- Puzzle Systems has NetWare server software
>>that runs on various Unix machines.
>
>Is that a clone, or is it a licensed implementation of 'portable netware'?

Puzzle's product is a clone, developed by looking at NCP wire traffic.
Novell has not attempted to go after them, probably because the code was
"clean room" developed, and also because you still have to buy a copy
of netware to get the administration utilities and client pieces.

From what I know of the product, it is a fast and fairly complete NW
3.1x clone.  However, they have their work cut out for them if/when
they attempt NW 4.x (netware directory services) emulation.


Mark Muhlestein -- mmm@park.uvsc.edu

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

From: dglaude@vub.ac.be (GLAUDE DAVID)
Subject: Re: InterLink for Linux
Date: 28 May 1994 23:25:52 GMT

Rob Janssen (rob@pe1chl.ampr.org) wrote:
: In <940527163549@lambada> steve.mcmahon@lambada.oit.unc.edu (Steve McMahon) writes:

: >So I'm wondering, has it been done for linux? If not, is there anyway
: >I can access the drive of a computer connected by a NULL-modem cable?
: >I realize one could use a comm program, but it's not the same. I'd
: >like to install things on my laptop using the CD-ROM of the desktop.

: It is a standard feature of the networking software.
: Setup a link using SLIP, CSLIP or PPP (serial ports), or PLIP (parallel ports)
: and you can connect two systems by a serial or parallel cable.
: Then you can just NFS-mount anything both ways.

First, I am sorry to disturb this Kernel only group. ;-)
Then I wanted to know about the compatibility issue between Linux [C]SLIP &
 PLIP and other implementation (Msdos ShareWare or Amiga Version).

I know it would be better if everyboddy use Linux on it's machine... but
 - I will need to use Linux as a file server for an other PC running Msdos
  or Windows.
 - A friend is deseprately trying to use a Linux-Box as a file server for his
  hard disk less Amiga.

Of course all of this without Ethernet card ;-) Only with a Parallel or Serial
 Cable.

I will happily collect any working solution with reference to the software and
 configuration used on both Linux and PC (or Amiga).

                Thank You.

---
        Try Linux without formating your disk, use UMSDOS FS.
type "finger dglaude@is1.vub.ac.be" for a signature! I speak French.

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

From: lgarde@scorch.hna.com.au (Leon Garde)
Subject: Re: SIGHUP - Where do we go from here?
Date: Sat, 28 May 1994 15:44:47 GMT

ken@chinook.halcyon.com (Ken Pizzini) writes:

>In article <1994May25.135713.31927@loreli.ftl.fl.us>,
>Sean Puckett <nate@loreli.ftl.fl.us> wrote:
>>So here's what we've learned.
>>  1.  Posix says SIGHUP should be sent only to session leaders.

>Posix says a SIGHUP generated by a terminal disconnect should
>only be sent to the controlling process associated with the
>terminal (1003.1-1988 sec. 7.1.1.10).  The "controlling
>process associated with the terminal" is the session leader
>that established the connection to the controlling terminal
>(sec. 2.3).

>Also, if a controlling process dies (whether by a call to _exit()
>or a SIG_DFL action), then SIGHUP shall be sent to each process
>in the foreground process group of the controlling terminal
>belonging to the dying process (1003.1-1988 sec 3.2.2.2).
foreground is the session leader and possibly another program
the session leader is running on your tty (and recieving characters
from your tty ).
what are stopped jobs also killed then.
OH DEAR Linux isnt POSIX compliant anyway. stopped processes are killed,
where 1003.1-1988 sec 7.1.1.10 says only foreground processes are to
be SIGHUP'ed .. or is it the shell killing the stopped processes ..

and what are running tasks ? 'bash' at least calls running tasks
that arent receiving characters from the tty a 'background' task.
does posix use the same definition ?


>SIGHUP generated other ways (i.e. via a kill() call) should
>be delevered wherever addressed, subject to permission constraints.

>               --Ken Pizzini
leon
-- 
leon garde; lgarde@scorch.hna.com.au

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

From: dhd@netcom.com (David H Dennis)
Subject: Re: Kernel change summaries
Date: Sun, 29 May 1994 03:29:31 GMT

I'll add to the general chorous of praise on this one.  This evening, my
dual-SCSI drive system with an UltraStor controller paniced with a SCSI
timeout.  By reading the kernel change summaries, I learned that was fixed
in 1.1.15 - so I will get that straight away without having to wait
breathlessly for an answer.

Thanks guys!

D

Try David's Amazing Internet Services:  Netnews with an original flair ...
(818) 997-7500.  It doesn't work just yet, but appreciates visits from
friendly (and unfriendly) sympathisers.

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

From: Lyle_Seaman@transarc.com
Subject: Re: Nfs Buffercache Brok
Date: Sun, 29 May 1994 00:06:07 -0400

Warning - advocacy follows.  I may be accused of being biased.

Russell.Coker@f363.n633.z3.fidonet.org (Russell Coker) writes:
>    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.  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.  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....

I'm sorry, but most of this is just plain wrong.  It's true that AFS
isn't the best thing for database work (but probably not for the
reason you cite), however, there's a school of thought which holds
that filesystems are not good for database work. As far as "only
logged in at one machine...", I routinely work from four different
machines simultaneously (two or three different architectures,
usually).  Most of the time I am editing files and reading netnews on
one machine, compiling on two other machines, and debugging programs
on the fourth. 

>    As far as the legal status goes, if a port to Linux can't be done
> then you could always write your own network filing system that had
> the same features.  The design of AFS is widely published....

I believe that someone at MIT is working on an AFS port to Linux.  

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

RFS and DFS provide slightly better cache coherence.  Other than
those, AFS provides the best "consistency" of any network filesystem
commercially available.  The client code does use more kernel memory
and disk space than NFS -- that's a conscious trade-off for improved 
performance and server scalability, and reduced network traffic.
Total solution cost is much less ('cuz you can use fewer and cheaper
servers). 

>   PS  I don't want to put you off developing this, but I beleive that
> there are many better ways of designing network systems for MOST
> applications (AFS is the best design for it's original usage at CMU).

Whoa.  You could probably get me to admit that AFS is not the best
design for SOME applications (like databases).  But it's pretty good
for MOST applications.

--
Lyle            Transarc                707 Grant Street
412 338 4400    The Gulf Tower          Pittsburgh 15219

"Gossip is what makes the world go round. I have very few secrets.
 I would be deeply concerned if a device were marketed that could stop 
 interception..."          Emma Nicholson, MP.    


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

From: ken@chinook.halcyon.com (Ken Pizzini)
Subject: Re: SIGHUP - Where do we go from here?
Date: 29 May 1994 09:34:50 GMT

>ken@chinook.halcyon.com (Ken Pizzini) writes:
>>Posix says a SIGHUP generated by a terminal disconnect should
>>only be sent to the controlling process associated with the
>>terminal (1003.1-1988 sec. 7.1.1.10).  The "controlling
>>process associated with the terminal" is the session leader
>>that established the connection to the controlling terminal
>>(sec. 2.3).
>
>>Also, if a controlling process dies (whether by a call to _exit()
>>or a SIG_DFL action), then SIGHUP shall be sent to each process
>>in the foreground process group of the controlling terminal
>>belonging to the dying process (1003.1-1988 sec 3.2.2.2).

In article <1994May28.154447.1252@scorch.hna.com.au>,
Leon Garde <lgarde@scorch.hna.com.au> wrote:
>foreground is the session leader and possibly another program
>the session leader is running on your tty (and recieving characters
>from your tty ).
>what are stopped jobs also killed then.
>OH DEAR Linux isnt POSIX compliant anyway. stopped processes are killed,
>where 1003.1-1988 sec 7.1.1.10 says only foreground processes are to
>be SIGHUP'ed .. or is it the shell killing the stopped processes ..

No, 7.1.1.10 says only the controlling process associated with the
terminal is to be SIGHUP'd; it's sec. 3.2.2 says only foreground
processes are to be SIGHUP'd when the controlling process dies.

Also, while the "controlling process associated with the terminal"
is a session leader, any process which calls setsid() will be
a session leader; a session leader is not necessarily in the
forground nor a controlling process.

>and what are running tasks ? 'bash' at least calls running tasks
>that arent receiving characters from the tty a 'background' task.
>does posix use the same definition ?

  1003.1-1988 sec. 2.3 General Terms.
  [...]
  forground process group.  Each session that has established a
  connection with a controling terminal has exactly one process
  group of the session as the forgreound process group of that
  controlling terminal.  The foreground process group has certain
  priveleges when accessing its controlling terminal than
  are denied to background process groups.  See Terminal
  Access Control sec. 7.1.1.4.

One of the mentioned priveleges mentioned in the 7.1.1.4 is that
foreground processes can read data from the controlling tty
without getting SIGTTIN (or -1/EIO if SIGTTIN is ignored or
blocked), so your definition pretty much works out to the same
thing.

And yes, my interpretation too is that Linux is not POSIX
compliant with regards to 3.2.2 item (6), based on the
black-box experimentation I've conducted.  (Actually,
the testing I've done can't distinguish between a 7.1.1.10
noncompliance or a 3.2.2 noncompliance; I'm just assuming
the latter.)  (I really should look at the kernel source
for this, but I'm being lazy this evening.)

                --Ken Pizzini

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

Crossposted-To: comp.os.linux.misc
From: Graham@rock.demon.co.uk (Graham Nicholls)
Subject: Re: PCI or VL bus SCSI Host Adapters
Reply-To: Graham@rock.demon.co.uk
Date: Thu, 26 May 1994 23:16:10 +0000

In article <1994May24.152813.22410@sifon.cc.mcgill.ca>
           daveh@texlin.minmet.mcgill.ca "Dave Hinz" writes:

> I phoned up several mail-order retailers the other day and learned from
> one (Micron) that the PCI bus interface has some serious problems in
> supporting SCSI-2 cards for 486 DX2-66 and 486 DX4-100 machines--they
> resultantly don't offer any!  Gateway is in the same boat.

And also if the problem applies to 90Mhz pentium systems, please.
Thanks

-- 
Graham Nicholls
Sig applied for.

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: InterLink for Linux
Reply-To: pe1chl@rabo.nl
Date: Sun, 29 May 1994 09:08:01 GMT

In <2s8ju0$6l1@rc1.vub.ac.be> dglaude@vub.ac.be (GLAUDE DAVID) writes:

>Rob Janssen (rob@pe1chl.ampr.org) wrote:
>: In <940527163549@lambada> steve.mcmahon@lambada.oit.unc.edu (Steve McMahon) writes:

>: >So I'm wondering, has it been done for linux? If not, is there anyway
>: >I can access the drive of a computer connected by a NULL-modem cable?
>: >I realize one could use a comm program, but it's not the same. I'd
>: >like to install things on my laptop using the CD-ROM of the desktop.

>: It is a standard feature of the networking software.
>: Setup a link using SLIP, CSLIP or PPP (serial ports), or PLIP (parallel ports)
>: and you can connect two systems by a serial or parallel cable.
>: Then you can just NFS-mount anything both ways.

>First, I am sorry to disturb this Kernel only group. ;-)
>Then I wanted to know about the compatibility issue between Linux [C]SLIP &
> PLIP and other implementation (Msdos ShareWare or Amiga Version).

Compatability of SLIP, CSLIP and PPP should be no problem.

PLIP is a different thing.  At first, it was compatible with the Crynwr
packet driver for parallel port.  Then, someone broke the compatability,
probably not knowing about it.  Now, some people are again working on the
PLIP driver to improve its efficiency, and I believe they also will restore
compatability.
I don't know about any Amiga compatability.

>I know it would be better if everyboddy use Linux on it's machine... but
> - I will need to use Linux as a file server for an other PC running Msdos
>  or Windows.
> - A friend is deseprately trying to use a Linux-Box as a file server for his
>  hard disk less Amiga.

>Of course all of this without Ethernet card ;-) Only with a Parallel or Serial
> Cable.

You must be a masochist... :-)
Of course it is possible, but don't expect much speed.  Buy an ethernet card.

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

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

From: djh@cs.mu.OZ.AU (David Hornsby)
Subject: Re: Appletalk support?
Date: Sun, 29 May 1994 12:19:00 GMT

ewt@merengue.unc.edu (Erik Troan) writes:
>>djh@cs.mu.OZ.AU (David Hornsby) writes:
>>>Porting CAP in "Native EtherTalk" mode to Linux is not feasible unless
>I think this already has been ported. Take a look at /pub/Linux/system/Network
>on sunsite - there are two files in there which begin with cap that ya'll 
>may find interesting.

These files are for IPTalk support under Linux only. They simply add Linux
to the Configure file and fix some #include file problems. To run with
IPTalk you will need an external gateway such as a FastPath, GatorBox,
Webster MultiPort or Cisco Router. CAP in Native EtherTalk mode (no
external router) isn't quite here yet ...

 - David
CAP Moderator pro tem.

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

From: thomas@troehl.hanse.de (Thomas Roehl)
Subject: Re: Routing requests and 1.1.15
Date: Sat, 28 May 1994 20:47:21 GMT

Mike Dowling (mike@MooCow.math.nat.tu-bs.de) wrote:
: When I boot I get 3 messages to the effect

: Warning: obsolete routing request made.

: It looks to me as if this results from the following 3 lines in my rc.inet1

: /sbin/route add localhost
: /sbin/route add tubs-net eth0
: /sbin/route add default gw 134.169.2.1 1

: If so, can anyone please tell me how this is now supposed to be done?
: (Everything nevertheless works fine.)

:       Mike Dowling
: --
: Dr. Michael L. Dowling                          (__)       on.dowling@zib-berlin.de
: Abteilung fuer Mathematische Optimierung  (oo)
: Institut fuer Angewandte Mathematik      \/-------\
: TU Braunschweig                                   ||     | \
: Pockelsstr. 14                                    ||---W||  *
: 38106 Braunschweig, Germany               ^^    ^^    Ph.: +49 (531) 391-7553

Hi,

I had that messages too. Then I recompiled route.c (dont't remember 
exactly from where I got it) and no more messages.

cioa, Thomas

-- 
Thomas Roehl      * thomas@troehl.hanse.de            * DATA / FAX :
Hamburg, Germany  * bbs: login "gast" no passwd       * +49 40 792 99 61
                  * nuucp: login "nuucp" pass "nuucp" * v32.bis  

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

From: dillon@apollo.west.oic.com (Matthew Dillon)
Subject: Re: Zombie problems
Date: 28 May 1994 14:03:51 -0700

In article <2s7r1b$m10@smurf.noris.de> urlichs@smurf.noris.de (Matthias Urlichs) writes:
:In comp.os.linux.development, article <2rtsi6$2dg@apollo.west.oic.com>,
:  dillon@apollo.west.oic.com (Matthew Dillon) writes:
:> 
:>     When a child process exits, it *always* becomes a zombie *until* the
:>     parent reads the child's exit code with wait(), waitpid(), wait3(), or
:>     wait4().
:> 
:Except when you set the SIGCHLD handler to SIG_IGN.

    Ach, I forgot about that.  UNIX is wierd in many respects and that is one
    of them.  I avoid SIG_IGN for SIGCHLD because it is inconsistant... for
    example, under linux if you initiate a wait() for a child which has not
    exited yet, with SIGCHLD set to SIG_IGN, it will not only block, but will
    also return the pid and status.  Under HP-UX, wait() blocks but then 
    returns -1.

:>     If you want to fork off a child and then not have to worry about dealing
:>     with his exit code later on, you can do a double fork:
:> 
:... or set SIGCHLD to SIG_IGN, or install a SIGCHLD handler which reaps
:the signal.

    There are many programs which use SIGCHLD but do not properly handle
    truncated returns from system calls such as read(), select(), accept(),
    etc... that occur due to getting interrupted.  Since such mistakes, as
    well as mistakes in writing the signal handler itself, can result in
    infinite loops, I try to avoid SIGCHLD signalling entirely.

:> [ double fork P
:>     Neat, eh?
:> 
:IMNSHO, the only sensible reasons why anybody would ever want to
:double-fork, and thus break the existing association between processes
:(and cause more load for the system), is (a) you want to exec() a process
:which might not like to have stray child processes thrust upon it, or (b)
:you're playing around with session IDs and/or process group IDs and/or
:controlling terminals.
:(Under some Unixes, setting these things only works with double-forking.)

    Not necessarily, there are many reasons why you might want to do this,
    not only for child-related effects, but also for parent-related effects.
    It only effects the system load if you are doing it all the time, which
    for most programs simply does not happen.

                                                -Matt

:Matthias Urlichs        \ XLink-POP N|rnberg  | EMail: urlichs@smurf.noris.de
:Schleiermacherstra_e 12  \  Unix+Linux+Mac    | Phone: ...please use email.
:90491 N|rnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42
:
:Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.


-- 

    Matthew Dillon              dillon@apollo.west.oic.com
    1005 Apollo Way             ham: KC6LVW (no mail drop)
    Incline Village, NV. 89451  Obvious Implementations Corporation
    USA                         Sandel-Avery Engineering
    [always include a portion of the original email in any response!]


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


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