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!