rbj@icst-cmr.arpa (Root Boy Jim) (04/23/88)
From: Chris Torek <chris@mimsy.uucp> >In article <561@neptune.AMD.COM> katni@neptune.AMD.COM (Katni V) writes: >> I need to read the VAX SID register. Is there a system function ... It will need more than that; the super user is still a user. I am not sure why you would want to do this; the SID register is grossly cpu-dependent and cannot be used as a serial number for software registration purposes, as some Vaxen do not have anything resembling a serial number in the SID (just various revision numbers). True, but it is likely that a given site might have all different `serial numbers'. This could be used, say, to divine the machine's hostname, allowing one copy of /etc/rc to be rdist'ed everywhere. Granted, the motivation for doing this is slight (and one could put the hostname line in it's own file and invoke it as `sh /etc/rc.hostname'), but someone might want to. If all you want is the CPU type, read the kernel variable `cpu'. It will be one of the VAX_xxx's defined in <vax/cpu.h>. Good point. In fact, why not just have locore.s grab the SID shortly after boot and stick it into a global variable `sid'? I seem to remember Chris long ago railing against myriad of `get interesting kernel variable' system calls. I would imagine his opinion has not changed on that matter. In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement It don't mean a THING if you ain't got that SWING!!
chris@mimsy.umd.edu (Chris Torek) (04/23/88)
I was not railing *against* the `get interesting kernel variable' syscalls, I was railing *for* them. There are too few. We could use a get_cpu_type syscall, in particular for the C library routines that use the fancy VAX instructions to do string operations. They run overly slow on the MicroVAX, since this machine traps on `locc' and `scanc' instructions and emulates them in the kernel. It would be nice, though, if it did not take a horrendous number of syscall table entries to describe all the interesting kernel variables; I argued for a call of the form get_kernel_variable(int variable_index) I still think this should be done. Chris
rbj@icst-cmr.arpa (Root Boy Jim) (04/23/88)
? I was not railing *against* the `get interesting kernel variable' ? syscalls, I was railing *for* them. There are too few. We could ? use a get_cpu_type syscall, in particular for the C library routines ? that use the fancy VAX instructions to do string operations. They ? run overly slow on the MicroVAX, since this machine traps on `locc' ? and `scanc' instructions and emulates them in the kernel. ? ? It would be nice, though, if it did not take a horrendous number ? of syscall table entries to describe all the interesting kernel ? variables; I argued for a call of the form ? ? get_kernel_variable(int variable_index) ? ? I still think this should be done. Um, maybe I wasn't clear (won't be the first (or the last) time :-). What I meant Chris meant is that he didn't want a separate syscall for *each* interesting variable. He effectively wants (how do those words taste that I'm putting in your mouth, Chris :-) to make nlist a system call. How many things do you point nlist at besides the kernel anyway? ? Chris (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement YOW!!! I am having fun!!!
chris@mimsy.umd.edu (Chris Torek) (04/23/88)
Make nlist a syscall? Not quite...!
The following might, however, be interesting: have a privileged program
dig out those `interesting numbers'---all the post-boot static ones,
anyway---and put them in a file, storing them at offsets derived from
the offset in /vmunix (or local equivalent).
Look Ma (Ma Bell? :-) ), a getdtablesize() C library function!:
int
read_saved_kernel_int(name)
char *name;
{
struct nlist nl[2];
int fd, rv;
nl[0].n_name = name;
nl[1].n_name = NULL;
if (nlist("/vmunix", nl)) /* something is wrong */
return (-1);
if ((fd = open("/etc/kdata", 0)) < 0)
return (-1);
(void) lseek(fd, (off_t)nl[0].n_value - (off_t)KERNBASE, L_SET);
if (read(fd, (char *)&rv, sizeof(rv)) != sizeof(rv))
rv = -1;
(void) close(fd);
return (rv);
}
int
getdtablesize()
{
return (_read_saved_kernel_int("_dtablesize"));
}
int
getcputype()
{
return (_read_saved_kernel_int("_cpu"));
}
/* ceteraque :-) */
Now all you have to do is write /etc/savekdata.dkc@hotlr.ATT (Dave Cornutt) (04/25/88)
In article <13089@brl-adm.ARPA> chris@mimsy.umd.edu (Chris Torek) writes: > I was not railing *against* the `get interesting kernel variable' > syscalls, I was railing *for* them. > ... > It would be nice, though, if it did not take a horrendous number > of syscall table entries to describe all the interesting kernel > variables; I argued for a call of the form > > get_kernel_variable(int variable_index) > > I still think this should be done. Yep, a lot of stuff like getpagesize and getdtablesize could be sucked up into this. Define a bunch of indices in an include file for naming the variables (it might be a good idea to divide them into hardware-independent and hardware-dependent partitions, with plenty of numbers reserved for future use in both). You might also want to make the syscall take a pointer to an area where it can deposit the value, so it can return string and structure items instead of just ints. -- Dave Cornutt, AT&T Bell Labs (rm 4A406,x1088), Holmdel, NJ UUCP:{ihnp4,allegra,cbosgd}!hotly!dkc "The opinions expressed herein are not necessarily my employer's, not necessarily mine, and probably not necessary"
greg@vertical.oz (Greg Bond) (04/29/88)
In article <337@hotlr.ATT> dkc@hotlr.UUCP (Dave Cornutt) writes: > > get_kernel_variable(int variable_index) >Yep, a lot of stuff like getpagesize and getdtablesize could be >sucked up into this. Define a bunch of indices in an include file >for naming the variables (it might be a good idea to divide them >into hardware-independent and hardware-dependent partitions, with >plenty of numbers reserved for future use in both). You might >also want to make the syscall take a pointer to an area where >it can deposit the value, so it can return string and structure >items instead of just ints. Does this sound like an IOCTL? Which has the advantage of encoding the arg size and mode into the IOCTL. What file to do the ioctl on? /dev/proc? Nasty portability problems, however. l i n e -- Gregory Bond, Vertical Software, Melbourne, Australia ACSnet: greg@vertical.oz, UUCP: uunet!vertical.oz!greg Gad! Did *I* start those lightbulb jokes?
allbery@ncoast.UUCP (Brandon Allbery) (05/04/88)
As quoted from <13091@brl-adm.ARPA> by rbj@icst-cmr.arpa (Root Boy Jim): +--------------- | Um, maybe I wasn't clear (won't be the first (or the last) time :-). | What I meant Chris meant is that he didn't want a separate syscall for | *each* interesting variable. He effectively wants (how do those words | taste that I'm putting in your mouth, Chris :-) to make nlist a system | call. How many things do you point nlist at besides the kernel anyway? +--------------- Xenix has /dev/sys/*. It doesn't even require nlist: open the pseudodevice in /dev/sys for what you want; /dev/sys/proc "contains" only used process table entries, etc. (Now if only Microshaft had provided *all* such devices: no /dev/sys/file or /dev/sys/inode, etc.) The devices are read-only for all, thus allowing "ps" to be non-set?id. -- Brandon S. Allbery, moderator of comp.sources.misc {well!hoptoad,uunet!marque,cbosgd,sun!mandrill}!ncoast!allbery Delphi: ALLBERY MCI Mail: BALLBERY