Andrew Gillham sez:
# Curt Sampson wrote:
# > 
# > 
# > Hmm. Isn't the CHANGES file pretty close to this?
# 
# Yup, it is, but it doesn't necessarily explain the ramifications of
# the change.  And I don't see the config changes there?  The idea
# was that the effect of the change might be listed, so there would
# be less confusion.  I'll list an example that I stumbled on,
#  which is my fault, no fault of the person committing the code.. :)
# 
# [change]
# Changed the reboot(2) system call to take (int bootopt, char *
#       bootstr) to allow smarter firmwire the ability to reboot
#       with a string.  [mrg 960809]
# 
# [effect]
# Old reboot(8) binaries will not be able to reboot a new kernel, they
# will core dump (leaving a zero length corefile), and will hang your
# system.  Make sure you update reboot(8) before attempting to reboot
# a -current kernel, as the filesystems will *not* be synced, and the
# only recovery is turning off the machine.  This affects at least
# i386 and sparc.  So, don't reboot(8) a remote machine and expect
# it to come back! 1/2 :)
# [or is this new reboot(8) with old kernel??  I already forgot]

Are you saying that if you have an old reboot(8) and execute it
under a new kernel, it will hang?

If it's the binary format, well, ok, I guess.

BUT if this is solely because of the parameter change to reboot(2), that's
bad.  Using the compiler to catch this is something of a crutch; had we a
straight K&R compiler and didn't use lint, we'd possibly be able to
stumble through and into this trap.  This is tantamount to execve(2)
crashing the system when called with an improper arg list (SunOS 3.2 did
this).  Neither one is acceptable, although execve() would be more serious
because _any_ schmutz can call it (whereas reboot(2) is a restricted
call).

...I don't suppose there was a way around this?  It seems bad coding,
but I'm not sure if that's the fault of the way the code is written
or if it's the fault of the compiler.

Are there any other system calls which have been changed like this?

Why the decision to reintroduce setreuid() as a system call, by the way?
I mean, it got yanked for some _fantastically_ good reason {/sarcasm}.

I saw something about SunOS compatibility.  I thought that was the
reason we had the SYS_compat* (what _are_ those routines called,
anyway) routines around in case of #ifdef COMPAT_SUNOS.

Just a few more rambling thoughts...  Sorry if I'm wasting bandwidth.

				--*greywolf;