lkml.org 
[lkml]   [1999]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: KMSGDUMP: dump kernel messages to a diskette
Hi Willy.

I've included most of your post for reference, as they are all
relevant to some extent to what I'm saying...

>> Just out of curiosity, how does it dump the messages out?

> there are two choices that can be made at kernel compile time
> (at the moment) :

> - dump blindly the raw 16 kbytes at the beginning of the disk.
> This can be retrieved simply by "dd if=/dev/fd0 bs=512 count=32"

> - creating a tiny FAT12 on the disk and dump the data in a file
> named "messages.txt". Easier to read.

> Any of the two methods DESTROY disk contents, but only require
> one track. It can be easy to find a diskette with useless
> contents. Even a damaged diskette can be used if its first track
> is good.

Agreed. However, a well designed version of the latter option would be
better, IMHO, hence the "Proof of Concept" in the enclosed tarball...

>> Whilst (1) is certainly the easiest to write, it's probably also
>> the least useful, and one of the other two would be prefeerable.

> yes and no ...

> Pavel Machek told me that people might think that if this system
> can use a FAT, then their disk contents won't be lost, which is
> false of course. I think he's right with this. That's the reason
> why I let the user choose.

> Personally, I use FAT because I find it easier to use, and I do
> know that my diskette contents will be lost after each dump.

You may like to try out the enclosed bash shell script, which formats
a floppy to maximise the data area thereon whilst still remaining
MS-DOS compatible enough that both MS-DOS 5.00 and Win95 can read the
floppies without any special driver.

In addition, it can insert a text file on the diskette whilst
formatting it, and the boot sector it writes will correctly boot into
a specialised version of MORE that pages through the said file. The
same code is also present as a file called README.COM on the formatted
disk.

For reference, on a standard 1440k diskette, it achieves 1436k of data
space for the files one wishes to put on it. I would anticipate it
getting 1196k on a 1200k floppy on the same basis, giving just 4k of
overhead in both cases.

> An improvement could be to dump messages each one after the
> other so that we could have a diskette full of kernel messages.
> This implies to be able to read FAT !

Not as hard as it sounds...especially if one is just extending one
large textfile. Handling lots of smaller textfiles would be more
complex though...

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
[unhandled content-type:application/octet-stream]
\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.074 / U:2.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site