netnews@wnuxb.UUCP (Heiby) (04/28/85)
Unix Technical Digest Sat, 27 Apr 85 Volume 1 : Issue 53
Today's Topics:
Extending the UNIX pathname, some experience
Foreign File Systems
Modem control in cu(1)?
----------------------------------------------------------------------
Date: Sat, 27 Apr 85 13:27:49 est
From: ima!johnl
Subject: Extending the UNIX pathname, some experience
The chaosnet implementation for 4.1 was largely my fault (we started
with some pretty reasonable code from IIASA, but it had never been
near real Chaos hardware before, nor interchanged packets with any
other Chaos hosts until we pounded on it at Yale 5 years ago.) There
was some surprisingly nice kernel hackery to allow multiple opens on the
same I-node for different connections, and to allow the driver to parse
the trailing part of /dev/chaos/kaflooga.
Passing the "kaflooga" to the driver was simplicity itself. I had but to
add one line to nami() which returned a success status if it ever found
itself looking at a character special file with the sticky bit set. At
that point, the various pointers in the U. block are all set up so that the
device open routine can retrieve the rest of the name with uchar(). Truly
a great hack, due to the IIASA people.
The multiple channel stuff appeared to be adapted from the V7 MPX file
stuff. What it did was to pun the seek offset in the kernel's per-open
"file" structure to be a pointer to a per-connection structure in the
device driver set up at open time. To avoid accidental system crashes,
we implemented a FMPX status bit in the file structure (already defined
in the V7 source; this had clearly been done before.) This bit disallowed
seek calls, since there was no seek pointer for such files, and fiddled the
close() logic so that it bypassed the usual logic that avoids calling a
device close routine when a special file is multiply open. This was also
a minor kernel change, less than 10 lines outside the driver, which did
just what we wanted.
Depending on the minor device number, some of the special files automatically
selected a host to connect to and a socket (TFTP) and passed the rest of
the filename to the other host. This meant that any file on our machine "ed"
which was a DEC-20 could be read by opening, e.g. /dev/ed/<system>message.txt
and reading it.
I'm not going to claim that this pair of kernel tweaks is a substitute for
a general scheme which allows a process to completely simulate a file,
including processing all of the client's system calls. But if you want
to put in something like labelled tapes or the chaos stuff in a finite
amount of time, it's not a bad way to go.
John Levine, Javelin Software, Cambridge MA 617-494-1400
{ decvax!cca | think | ihnp4 | cbosgd }!ima!johnl, Levine@YALE.ARPA
------------------------------
Date: 25 Apr 1985 20:51:28-EST (Thursday)
From: Josh Knight <ucbvax!JOSH.YKTVMH%ibm-sj.csnet@csnet-relay.arpa>
Subject: Foreign File Systems
First, a comment on Jack Jansen's proposal (which is appended at the end).
A long time ago, I implemented a block oriented interface to another
file system (the RC4000 Time Sharing System, see Per Brinch Hansen's book
on Operating Systems). I can't remember now, but I think it worked both
on a PDP 11/45 and the subsequent Vax....there is no suggestion that such
is currently of interest. The real point is that it seems appropriate
to do the sorts of things that Jack suggests with /dev/blahblah and a
modification to open (ychhhh) with a run-time-library and NOT kernel
mods. Programs that wish to access the foreign/remote files/file
systems will have to be recompiled in any event and the run time library
approach allows development AND changes to be made without taking the
system down. If you are absolutely enthralled with the idea of saying
open("/dev/blahblah", 1, "ARAD50.FIL")
do it with the preprocessor and an include file. One can also have low
performance access to a foreign file system by just copying a (presumably
small) foreign file system to a regular file. I had my code all set up
to use a raw device for speed, but never found it necessary (just as the
write code was never tested). In a nice implementation, commands/calls
like mount_rt11 (or whatever) could make the appropriate correspondence
between /dev/correct_disk or .../path/right_file and the foreign file
system.
Just out of curiosity, does the following bug still exist in System V?
Try making a file with a HUGE (like 100 Mbyte) hole in the middle. Then
dump/restor the file. The bug I'm thinking of will evaporate all of the
hole that is represented by non-existent doubly indirect blocks. Not
nice if the file system (or data base or whatever) has it's own index
into the file. I expect the 4.2 file system is sooo different that this
bug has not propagated from 4.0 or 4.1, whichever it was I found it on.
I think I submitted a fix for it at the Usenix meeting in Austin in June
of 1981, but I can't remember. It was exposed by trying to dump/restor
a regular file that had a (rather large, actually) RC4000 file system on
it. Anyway...just curious.
Of course, any opinions, expressed or implied are mine and not my
employers...
Josh Knight
IBM T.J. Watson Research Center
josh@yktvmh.BITNET, josh.yktvmh.ibm-sj@csnet-relay.ARPA
-.-.-.-.-.-.appended article from Unix-Wizards.-.-.-.-.-.-.-.-
> From: jack@boring.UUCP
> Subject: Re: Extending the UNIX pathname syntax
> Date: 24 Apr 85 15:19:33 GMT
> To: unix-wizards@brl-tgr.arpa
>
>
>
> Something like /dev/net/blablabla is something that I've wanted
> to implement for a long long time now, only I haven't found
> the time yet.
> The things you can do with this are numerous :
> - more-or-less transparent access to files on other machines.
> - magtape labeling (as stated in the previous article).
> - using RSX-11(yucc), MS-DOS(Yucc), RT-11(WAAAAAAAAAAAHHH!!) or
> whatever filesystems under unix.
> - A 'shell device' (something like fd=open("/dev/sh/ls -l",0).
> - And, of course, combinations of the above. Think of
> /dev/net/othermachine/dev/sh/ls -l
>
> The implementation is also quite straightforward:
> 'open' gets a third parameter (the rest of the string after the
> device name), and returns a pseudo-inumber, and all the other
> routines are passed this inumber (if you want to be able to
> do seeks and stats on these 'funny' files, you need some more
> stuff, but nothing difficult).
>
> Has anyone implemented something like this already? Anyone feels
> like doing so? Any comments?
> --
> Jack Jansen, {decvax|philabs|seismo}!mcvax!jack
> The shell is my oyster.
>
------------------------------
Date: Fri Apr 26 08:09:08 1985
From: ihnp4!uw-beaver!tektronix!reed!omen!caf
Subject: Modem control in cu(1)?
How can a program such as cu(1) test for the presence/absence of carrier
detect on the line it is calling out on ? SIGHUP is associated with the
controlling terminal; I need to know about the line I'm calling out with.
Also, how can I detect framing errors and breaks on the line I'm calling
out on?
--
Chuck Forsberg WA7KGX ..!tektronix!reed!omen!caf
Omen Technology Inc 17505-V NW Sauvie IS RD Portland OR 97231
Voice: 503-621-3406 Modem: 503-621-3746 (Hit CR's for speed detect)
------------------------------
End of Unix Technical Digest
******************************
--
Ronald W. Heiby / netnews@wnuxb.UUCP | unix-request@cbosgd.UUCP
AT&T Information Systems, Inc., Lisle, IL (CU-D21)