Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!oddjob!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: POSIX execlfd and execvfd proposal
Message-ID: <9571@mimsy.UUCP>
Date: Mon, 30-Nov-87 11:35:57 EST
Article-I.D.: mimsy.9571
Posted: Mon Nov 30 11:35:57 1987
Date-Received: Thu, 3-Dec-87 06:56:10 EST
References: <18491@linus.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 31

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.

True enough.

>What do you think about adding the following two system calls, execlfd
>and execvfd? ...  These exec's [would] replace the current process with
>a new image.  Before replacing the image, but after determining the
>identity of the file to be exec'ed, they open the binary image and
>place the file descriptor in an external int called "boot_fd" [in
>the new image!].

Points:
 0) hard to implement (kernel has to look for symbol table!)
 1) does not help programs that are run by the old exec calls
 2) as a side issue, there is no execl system call; only execve
    is in fact a syscall (the rest can be done with library
    routines).

A much simpler method for getting a handle on the current process's
file would be to have a /dev entry that can be opened for (at least)
reading.  It would mean that the kernel would have to `open' and
`close' files being executed, so that while they run, they cannot
be removed, but this is already true for all but OMAGIC files.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris
Anagrams: Ate rock, cork tea, a rocket: racket, O!