Messages in this thread | | | Date | Sun, 4 Jul 1999 00:39:51 +0100 (GMT) | From | Riley Williams <> | Subject | Re: 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] | |