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