home *** CD-ROM | disk | FTP | other *** search
- 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
-
-