limits

[Moderator, John Quarterman]

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