Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site ut-sally.UUCP Path: utzoo!watmath!clyde!burl!ulysses!gatech!seismo!ut-sally!std-unix From: std-unix@ut-sally.UUCP (Moderator, John Quarterman) Newsgroups: mod.std.unix Subject: Re: limits Message-ID: <3598@ut-sally.UUCP> Date: Thu, 21-Nov-85 08:28:19 EST Article-I.D.: ut-sally.3598 Posted: Thu Nov 21 08:28:19 1985 Date-Received: Sat, 23-Nov-85 04:36:55 EST References: <3575@ut-sally.UUCP> Organization: IEEE/P1003 Portable Operating System Environment Committee Lines: 82 Approved: jsq@ut-sally.UUCP Date: Wed, 20 Nov 85 13:47:00 est From: seismo!cbpavo.cbosgd.ATT.UUCP!mark (Mark Horton) After looking at the cc -E / sed approach to reading limits.h, I wanted to pass along a couple of other ideas. (There are lots of UNIX systems out there that don't have C compilers on line, in particular, both Xenix and the AT&T 3B2 come without them until you add them in, and they take up enough cash and disk space that I'll bet many non-hackers won't install them.) One idea is to do what netnews does to figure out the system name. I'll enclose the code at the end (the code is public domain) but basically it opens /usr/include/whoami.h and looks for a line #define sysname "whatever" and extracts the "whatever". It uses scanf, but hard code could be written to make this a bit faster and more robust. It does depend on the full path name /usr/include/file.h, and it does expect the #define to be in a reasonably standard format, but these aren't overly cumbersome restrictions, are they? (Dare we assume that /usr/include will be there on all systems, even those without compilers?) Another idea is a bit more complex, but solves the "two copies of the information" problem while still keeping a non-C file like the proposed /etc/limits. The idea is to keep a single copy in /etc/limits, and use the obvious subroutine to get the values for user code (which then has to malloc things.) But the kernel has to know these numbers too, and it's not exactly reasonable for the kernel to go opening up a user file. Perhaps a user program can be written that will read the file, and download it into the kernel with some kind of (system dependent) magic, such as poking in /dev/kmem, or a special ioctl, or whatever. Then the kernel can malloc the appropriate data structures for the appropriate sizes. This second idea has a chicken-and-egg problem, in that the data structures better be allocated EARLY, and the obvious place to do the downloading is /etc/rc, which is awfully late for such things. One possibility is for /etc/init to do this before it does much of anything else, although this is still probably too late (after all, it has to open the file, and this means the file table has to exist. Also, it's a process, so the process table must exist.) One possibility for handling this is for the kernel to have a very small set of minimal tables to use until the real numbers come in, at which time it swings a new pointer to the new tables. (This is getting pretty ugly, isn't it?) A third possibility is for the kernel to use the limits.h file, but for /etc/rc to run a program that reads the values, translates them into an easily parsed format (possibly binary), and puts these values into /etc/limits. Then the hard work is done only once per boot. This might make it hard to write programs like fsck that run single user, however. Mark #define HDRFILE "/usr/include/whoami.h" uname(uptr) struct utsname *uptr; { char buf[BUFSIZ]; FILE *fd; fd = fopen(HDRFILE, "r"); if (fd == NULL) { fprintf(stderr, "Cannot open %s\n", HDRFILE); exit(1); } for (;;) { /* each line in the file */ if (fgets(buf, sizeof buf, fd) == NULL) { fprintf(stderr, "no sysname in %s\n", HDRFILE); fclose(fd); exit(2); } if (sscanf(buf, "#define sysname \"%[^\"]\"", uptr->nodename) == 1) { fclose(fd); return; } } } Volume-Number: Volume 3, Number 32