Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!cornell!uw-beaver!tektronix!zehntel!vlsvax1!qantel!dual!lll-crg!gymble!umcp-cs!seismo!brl-tgr!tgr!scc%cl-steve.cam@ucl-cs.arpa
From: scc%cl-steve.cam@ucl-cs.arpa (Stephen Crawley)
Newsgroups: net.unix-wizards
Subject: Extending the UNIX pathname syntax
Message-ID: <10102@brl-tgr.ARPA>
Date: Mon, 22-Apr-85 04:51:43 EST
Article-I.D.: brl-tgr.10102
Posted: Mon Apr 22 04:51:43 1985
Date-Received: Thu, 25-Apr-85 07:44:21 EST
Sender: news@brl-tgr.ARPA
Lines: 42

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)