sgf@cs.brown.edu (12/21/89)
Once upon a time BSD had a kernel datum called hostid. This was typically assigned a number fetched from a prom at boot time. It's value was returned by gethostid(2) and was set by root with sethostid(2). Sun wisely (some say) decided to do away with sethostid and the kernel variable "hostid". They decided to have gethostid() return a value fetched from the prom each time gethostid was called (I learned this long ago from grovelling through the kernel with adb - not from sun_src). >Hint: Copy /vmunix to /vmunix.save. There is a procedure in /vmunix >called "gethostid". Disassemble it with "adb". Replace the call to >"machineid" with an instruction (680x0) or two (SPARC) that will set the >result (d0 or %o0) to the CPUID you are interested in. While it's perfectly legal to mangle your kernel this way you could get into nasty trouble if you use it to run software illegally. The only nice advantage to this would be that it would make it easy to move the software from one machine to another without having to hassle with new passwds and such. If you're going to go to the trouble of mangling a kernel with adb you've probably built a kernel before. Sun has always included init_sysent.c with BINARY distributions. For those of you who don't know, init_sysent.c is to system calls what conf.c is to device drivers - an array of function pointers. The index into the array for devices is known outside the kernel as the major device number. The index into the array of system calls is referenced by the appropriate library routines in libc.a (ie, jump to kernel mode and execute system call N, where N is the index in the init_systent.c array). What this means is that users with binary licenses can add their own system calls.