Messages in this thread | | | Date | Sun, 09 May 1999 11:48:51 +0200 | From | Manfred Spraul <> | Subject | Re: New Partition Type |
| |
Riley Williams wrote: > > 1) syslogd (user mode program, i.e we need the scheduler) > > 2) the filesystem > > 3) the buffer cache > > 4) the device driver > > 5) the interrupt handler > > 6) bottom-half handling > > For it to be useful, we would need to omit 2, 3, 5 and 6 from that > list on an oops, as they can't be guaranteed to be safe to use. We > would therefore be writing direct to the raw disk.
This will be very difficult: there are many different disk controllers, and I think that a special 'safe' device driver just for the logs (one for every controller) won't go into the main kernel. Supporting IDE would be nice, but the SCSI code contains far more bugs (just because it's larger), i.e. a solution for SCSI systems is very important.
> > special file: > > This has the advantage that this would be portable. > > Not necessarily - it will probably require dedicated code for the > relevant type of disk, EIDE or SCSI or whatever future types develop.
I never though about writing a special purpose 'safe' device driver. A special file would just bypass the filesystem, and the syslogd. This approach requires that the buffer cache, the interrupts, and the bottom half handler are still operational.
I think: - support for writing the oops to the printer. A patch for this already exists.
- support for writing the oops to the floppy. Most computer (regardless of the HD-interface) have a floppy. I've read the netware uses a floppy for their oops. But AFAIK, the floppy controller is complicated: lots of timeouts, wait for the drive to spin up, etc.
- add 'wait n seconds on oops' - kernel parameter (there is such an entry for 'wait on panic') IMHO, this should go into the main kernel - very simple, paper & pencil never overwrite your harddisk ;)
- broadcast the oops over the network. I haven't though about the side effects. The implementation would depend on interrupts and bottom-half handlers, but at least it would be independant of the disk subsystem system.
Regards, Manfred
- 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/
| |