Jerry Gilliam wrote: >... > >OPTIONS > The following options are supported: > > -d Force a system crash dump before rebooting. See > dumpadm(1M) for information on configuring system > crash dumps. > > > -e If -f is present, reboot to the specified boot | > environment. | > | > | > -f Fast reboot bypassing firmware and boot loader. The > | > new kernel will be loaded into memory by the running > | > kernel, and control will be transferred to the loaded | > kernel. If disk or kernel arguments are specified, | > they must be specified before other boot arguments. | > See Example 3 for details. | > | > Currently only available on x86 system. | > | > > -l Suppress sending a message to the system log daemon, > syslogd(1M) about who executed reboot. > > > -n Avoid calling sync(2) and do not log the reboot to > syslogd(1M) or to /var/adm/wtmpx. The kernel still > attempts to sync filesystems prior to reboot, except > if the -d option is also present. If -d is used with > -n, the kernel does not attempt to sync filesystems. > > > -q Quick. Reboot quickly and ungracefully, without shut- > ting down running processes first. > > >OPERANDS > The following operands are supported: > > boot_arguments An optional boot_arguments specifies argu- > ments to the uadmin(2) function that are > passed to the boot program and kernel upon > restart. The form and list of arguments is > described in the boot(1M) and kernel(1M) > man pages.. If the arguments are speci- > fied, whitespace between them is replaced > by single spaces unless the whitespace is > quoted for the shell. If the > boot_arguments begin with a hyphen, they > must be preceded by the -- delimiter (two > hyphens) to denote the end of the reboot > argument list. > >... > Example 3 Fast reboot | > | > Check if all the drivers on the system are fast reboot capable. | > | > example# reboot -f dryrun | > | > Rebooting to another UFS root disk. | > | > example# reboot -f -- '/dev/dsk/c1d0s0' | > | > Rebooting to another ZFS root pool. | > | > example# reboot -f -- 'rootpool/root1' | > | > Rebooting to "mykernel" on the same disk with "-k" option. > | > | > example# reboot -f -- '/platform/i86pc/mykernel/amd64/unix -k' | > | > Rebooting to "mykernel" off another root disk mounted on /mnt. | > | > example# reboot -f -- '/mnt/platform/i86pc/mykernel/amd64/unix -k' | > | > Rebooting to "/platform/i86pc/kernel/$ISADIR/unix" on another boot > | > environment named "second_root". | > | > example# reboot -f -e second_root | > | > Rebooting to the same kernel with "-kv" options. | > | > example# reboot -f -- '-kv' | >
Hmmm... My only comment from the above is that the architecture of reboot(1m) doesn't make it clear which of the sub commands come from uadmin(2), boot(1m) or kernel(1m). This leads to a number of comments that are documentation related, and perhaps not architectural. For example, if the "reboot -f dryrun" wasn't present, how would one even guess that this is valid? And how would I know to use "dryrun" rather than "DRYRUN" or some other magic string? Does its presence meant that I can also do "reboot -f remount"? It may be that the faults in this man page aren't all the problem of this project but it would be nice if reboot(1M) became more meaningful as a result of this update and documented at least which of the uadmin(2) options were supported by which args to reboot(1m). The examples where you've used '--' are also confusing as it conflicts with the documentation about that says they only need to be used when the next arg start with a '-'. e.g. why isn't it # reboot -f /mnt/platform/i86pc/mykernel/amd64/unix -- -k Given the situation is now (or always was) more complex, I'd suggest either updating the man page further or keeping your examples in line with the existing docs. Darren
