lkml.org 
[lkml]   [1999]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.045 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site