Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!munnari!otc!metro!basser!elecvax!neilb
From: neilb@elecvax.eecs.unsw.oz (Neil F. Brown)
Newsgroups: comp.unix.wizards
Subject: Re: POSIX execlfd and execvfd proposal
Message-ID: <3851@elecvax.eecs.unsw.oz>
Date: Wed, 2-Dec-87 17:51:52 EST
Article-I.D.: elecvax.3851
Posted: Wed Dec  2 17:51:52 1987
Date-Received: Mon, 7-Dec-87 00:11:33 EST
References: <18491@linus.UUCP> <564@aoa.UUCP>
Organization: EE and CS, Uni of NSW, Sydney, Australia
Lines: 52

Mark of the Valley of Roses writes:
>In article <18491@linus.UUCP> ramsdell@linus.UUCP (John D. Ramsdell) writes:
>>In writing programs that dynamically load code, one usually needs to
>>know from which file the executing image was exec'ed.  I conclude from
>>my own review of Draft 12 of the POSIX standard (P1003.1), that there
>>is no way of knowing this information.  What do you think about adding
>>the following two system calls, execlfd and execvfd?
>
>He then goes on to describe system calls which would provide the exec'ed program
>with a file descriptor which could be used to read the file.
>
>You've identified a real problem, but  ...
>
>.....  The desired result could be achieved by adding a
>new special file (and device driver) which any program could open to read
>the file from which it was exec'ed.
>-- 

I have two small comments to make.

The first is about this idea of a new special file and device driver.
What is suggested is writing code to fiddle with file descriptor for you,
and making it look like a character special device. It hardly seems the right
place to put the code to me. After all, its not a character device that we
want opened (or that we get).
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.

The second is that we should look at this problem of accessing a processes
object file a bit more deeply.
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.
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.

Ideally, each of these should be available on an equal standing with other
descriptors (though the semantics of closing them would need careful thought).
Maybe they could be file descriptors -1 -2 -3 -4 - or maybe not, there could
be problems.
Anyway, its food for thought.

NeilBrown