Path: utzoo!mnetor!uunet!husc6!hao!oddjob!gargoyle!ihnp4!cbosgd!mandrill!hal!ncoast!allbery
From: allbery@ncoast.UUCP (Brandon Allbery)
Newsgroups: comp.unix.wizards
Subject: Re: POSIX execlfd and execvfd proposal
Message-ID: <6363@ncoast.UUCP>
Date: 8 Dec 87 00:09:52 GMT
References: <18491@linus.UUCP> <564@aoa.UUCP> <3851@elecvax.eecs.unsw.oz>
Reply-To: allbery@ncoast.UUCP (Brandon Allbery)
Followup-To: comp.unix.wizards
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 54

As quoted from <3851@elecvax.eecs.unsw.oz> by neilb@elecvax.eecs.unsw.oz (Neil F. Brown):
+---------------
| This all started with the /dev/fd drivers. Very useful things, but not really
| devices. The problem is that there isn't a clean place in Unix to but this
| functionality, so one should be made.
| Probably a new file type,
| 	mode & IFMT == IFFILEDESC
| or something like that.
+---------------

May I suggest that an existing feature in BSD UNIX could be generalized to
provide this?  Why not generalize "bind"?  (i.e. "flink()")

As for the file descriptor of an executable -- sounds like the process file
system of V8 is the best way to do this.  Either another special file system
or an ioctl() or fcntl() on a "file" in /proc could do this.

In fact, it seems to me that the two facilities might be generalized together,
thus also producing shared-memory "files" and other exotic (exotic?  Tell
that to Xenix!) critters.

+---------------
| The problem as I see it is that there are 20+4 (or 64+4 or whatever) file
| descriptors available to a process, of which only 20 (or 64..) are first
| class citizens.
+---------------

80 (+4) [3B1.  Golly, it even beats 4.3BSD!  ;-)]

+---------------
| The other four are
| 	current directory	- available by opening "" or "."
| 	root directory		- available as "/"
| 	controlling termial	- "/dev/tty" (probably)
| 	processes object file	- not currently available.
| Admittedly the controling terminal is not stored as a file descriptor,
| but it easily could be.
+---------------

I thought V8 put /dev/tty on fd 127?

+---------------
| Ideally, each of these should be available on an equal standing with other
| descriptors (though the semantics of closing them would need careful thought).
+---------------

With the exception of the process's object file, I'd disallow close() on those
fd's; close() should probably return EINVAL. One could argue for the tty fd
being closeable, however; the result should be to both close the tty and
detach the process from the terminal (set pgrp to 0 or to pid).
-- 
Brandon S. Allbery		      necntc!ncoast!allbery@harvard.harvard.edu
 {hoptoad,harvard!necntc,cbosgd,sun!mandrill!hal,uunet!hnsurg3}!ncoast!allbery
			Moderator of comp.sources.misc