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