As fdisk is in the utils-linux package, I've cc'd this response to the
maintainer thereof for comment...
> I have a new idea: what about supporting 'fast reboot', and then
> we can use this 'fast reboot' feature for the oops-reboot.
> 1) what's 'fast reboot'. Windows 95 has the feature that you can
> reboot Windows without restarting the computer, i.e. not BIOS
> self test. Much faster. It's implemented by an old DOS program
> that sits below Windows: (WIN.COM) if Windows exits with return
> code 0x42, then it will restart windows instead of shutting
> down the computer.
This works because Windows sits on top of DOS, and DOS itself has such
a simple map of how things work that it's almost impossible for it to
go wrong. Linux doesn't have an equivalent.
Also, any option involving a reboot is dependant on the loader used to
load the Linux kernel being the first thing the system does on reboot,
so it rules out systems that need to use loadlin or equivalent loaders
to boot.
Personally, I would see oops-handling as a system-dependant config
option, with the following as possibilities:
1. Write the oops to a dedicated oops partition.
No such partition type currently exists, so one would need to be
designed. Personally, if such was to be done, I'd prefer to see
a dedicated syslog partition rather than one that just handled
oops, with all syslog data being written to the partition using
a crash-safe method.
2. Write the oops to the tail end of a designated swap partition, and
have swapon check for an oops in each swap partition it mounts,
and write any oops found to syslog before mounting the partition.
This option requires the system to have a swap partition, which
isn't always the case.
3. Perform a WARM reboot, which skips the memory test phase of the
POST on most systems.
This option requires that whatever loads the Linux kernel is the
first thing to be run by the bootup process.
If it's of interest, I'd be willing to have a go at writing the driver
for option (1) above, with the aim of making it safe for use in most
oops scenarios. There's little I could do to protect against its being
overwritten other than insist that it's either absent or hard compiled
into the kernel, as loading a module would be inherently unsafe in the
cases where it's most needed.
If there's support for this, I would start by proposing a partition
type number for it, my choice being 0xfc as 252 decimal is said to be
one of my lucky numbers, and doesn't appear to be in use.
Andries: Can you confirm this?
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/