scc%cl-steve.cam@ucl-cs.arpa (Stephen Crawley) (04/22/85)
In a message on labelled tapes, Doug Gwyn writes > This is getting silly. How are you going to specify a label to > something like: > myprog > /dev/rmt0 What about myprog > /dev/rmt0/thelabel In more general terms, it ought to be possible to pass device or socket specific parameters in the open() pathname. When resolving a pathname, the kernel knows that the inode corresponding to rmt0 is a special file. Why not simply pass any characters following rmt0/ through to the device driver's open routine for interpretation? The string after the / does not even have to conform to the contentional pathname syntax. There are many places where this would be useful. For tapes, there are not only labels to specify. Tape density, rewind-on-close and other parameters which are currently handled by stealing bits from the minor device number would be better handled this way. It is cleaner, and would make it possible to take out a lock on a tape drive [advisory in 4.2 Bsd, hard in Sys V] without having to worry that a tape drive has many inodes [/dev/rmt0 /dev/mt0 etc.]. A more interesting use of a mechanism like this would be for specifying the name of a network service and service specific open parameters to a network access device. The current method for doing this in the absence of 4.2 Bsd style networking is to open a network channel device, and specify the service name and connection parameters by means of ioctls. 4.2 Bsd is better, but it is still necessary to use different mechanisms [connect() rather than open()] to set up a network connection, and it provides no generalised way of sending ``open parameters'' [some protocol families can't do without them ... but that is another matter]. I've provided enough canon fodder for now ... what do people think? Stephen C. Crawley ARPA: scc%cl.cam.ac.uk@ucl-cs.ARPA SMail: Cambridge University Computer Lab., JANET: scc@uk.ac.cam.cl Corn Exchange Street, PHONE: +44 223 352 435 Cambridge CB2 3QG, England. USENET: ....!mcvax!ukc!camjenny!scc (might work)
louie@umd5.UUCP (04/22/85)
In article <10102@brl-tgr.ARPA> scc%cl-steve.cam@ucl-cs.arpa (Stephen Crawley) writes: >In more general terms, it ought to be possible to pass device or socket >specific parameters in the open() pathname. When resolving a pathname, the >kernel knows that the inode corresponding to rmt0 is a special file. Why not >simply pass any characters following rmt0/ through to the device driver's open >routine for interpretation? The string after the / does not even have to >conform to the contentional pathname syntax. In fact, this is already implemented in a version of UNIX for the Sperry 1100 series hardware. UNIX on the Sperry runs "on top" of the existing 1100 OS. There is a driver in UNIX that allows users in the UNIX environment to access regular OS1100 files and elements. The way that you do this is /u/QUAL*FILE.ELT where stuff after the /u/ is interpreted as an 1100 file or element name. There's a hack in namei() to detect the special i-node for /u. -- Louis A. Mamakos WA3YMH University of Maryland, Computer Science Center Internet: louie@umd5.arpa UUCP: {seismo!umcp-cs, ihnp4!rlgvax}!cvl!umd5!louie
long@ittvax.UUCP (H. Morrow Long [Systems Center]) (04/23/85)
In <10102@brl-tgr.ARPA> Stephen C. Crawley (mcvax!ukc!camjenny!scc ) writes > In a message on labelled tapes, Doug Gwyn writes > > This is getting silly. How are you going to specify a label to > > something like: > > myprog > /dev/rmt0 > > What about > myprog > /dev/rmt0/thelabel > > In more general terms, it ought to be possible to pass device or socket > specific parameters in the open() pathname. ....... In the chaosnet implementation for 4.1bsd the nami.c routine has been modified to check to see if the inode obtained (so far) in parsing the filename is a character special file with the setuid bit on (a unique usage) and, if so, stop decoding and pass the remainder of the filename back to open() and allow the chaos driver to use the network address. This would allow the following: return_code = open ("/chaos/2002",2); -- H. Morrow Long ITT-ATC Systems Center, 1 Research Drive Shelton, CT 06484 Phone #: (203)-929-7341 x. 634 path = {allegra bunker ctcgrafx dcdvaxb dcdwest ucbvax!decvax duke eosp1 ittral lbl-csam milford mit-eddie psuvax1 purdue qubix qumix research sii supai tmmnet twg uf-cgrl wxlvax yale}!ittvax!long
jack@boring.UUCP (04/24/85)
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.dfk@unido.UUCP (04/26/85)
>/***** unido:net.unix-wizar / boring!jack / 7:19 pm Apr 24, 1985*/ > >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. Well it sure sounds nice. >Has anyone implemented something like this already? Anyone feels >like doing so? Any comments? If I remember it correctly, a similar idea was in the original proposal for networking from UCB. It was a special socket called a "portal". A process listening to such a socket would be passed the "blablabla" part of the pathname. I am not sure wether the automatic creation of the server was in the proposal too. It sounds like a very clean (UNIX like) way to assign names to many things we currently name in rather crude ways. Since nothing of the sort is in 4.2 this seems not to be that trivial to implement and I don't get the impression that people at Berkeley are still thinking about it. Does anybody have an idea why this is so ? -Daniel Karrenberg <dfk@unido.uucp>
djl@fisher.UUCP (Dan Levin N6BZA ) (04/27/85)
> Jack Jansen, {decvax|philabs|seismo}!mcvax!jack > Has anyone implemented something like this already? Anyone feels > like doing so? Any comments? My XENIX 3.0 machine (Intel 310/286) uses this sort of thing to access MS-DOS floppies. You specify /dev/floppy:msdos_pathname to a group of MS-DOS related commands. Works rather well. Also, V8 uses this exact method to do networking. /dev/machine_name/pathname gets you a file on another machine transparently. -- ***dan {allegra,astrovax,princeton,twg}!fisher!djl The misplaced (You call *that* a ski slope??) Californian
chris@umcp-cs.UUCP (Chris Torek) (04/29/85)
> Also, V8 uses this exact method to do networking. /dev/machine_name/pathname > gets you a file on another machine transparently. I feel like quibbling: make that ``as transparently as possible''. Remote file access is never going to be quite the same as local file access (if only because the other machine could be down). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
tanner@ki4pv.UUCP (Tanner Andrews) (05/03/85)
Yes, your (and our northern branch's) intel boxes do accept the funny- looking stuff with a pathname like "/dev/dvf0:foobar.exe". It should be noted, however, that this is done by having the "dos___" commands parse the filename specially. There is NO support for this in the op system, or even in any other progs besides the special ms-dos disk processing progs. To save a little typing, you might define the following entry in the file /etc/default/msdos (if it does not exist): A=/dev/dvf0 B=/dev/dzf0 Then, when you want to access ms-dos disks, you may say "dos___ A:/foo" instead of "dos___ /dev/dvf0:/foo". Case matters in the "A:..." syntax. -- <standard disclaimers apply, copies upon request> Tanner Andrews, KI4PV