>> 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.
True - and I for one would expect the diskette to get destroyed
anyway, in these circumstances. Certainly the second option would be
my preference though...
> The dump code is the same, it simply looks at a bit in some
> flags to know if it must write a FAT or not.
Nodz...
>> 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 sounds like the argument that because Linux is best installed
in an ext2 partition, it can be installed without destroying one's
Windows setup, since ext2 must be a subset of FAT32 !!!
> That's the reason why I let the user choose. Personnaly, I use
> FAT because I find it easier to use, and I do know that my
> diskette contents will be lost after each dump.
The only diskettes whose contents I keep permanently are master
diskettes for software I've obtained at some time or other, and other
than that, I expect my floppies to be regularly reformatted between
FAT12 and ext2 as needed...
> 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 necessarily - the FAT12 filesystem is wonderfully resiliant in
many ways, and it's quite legitimate to format what's really a 1.4M
diskette with 40 tracks, 1 head and 8 sectors per track., thus giving
it a capacity of 160k. Generate a FAT12 header that says there's only
a single file on the disk, its name being PANIC.IMG (or whatever), and
both FAT tables indicating that it occupies the entire disk, then
write out that header followed by however much messages fit in the
remainder and you're laughing.
Since we're talking of Linux and it requires at least a 386 to run, we
can probably assume a basic minimum spec of 2 heads and 9 sectors per
track, and either 40 or 80 cylinders as appropriate (I believe there's
a BIOS call that can return that information), so make that either
360k or 720k of messages as appropriate.
*** Time passes ***
Oooooopppsss......
I hadn't realised this didn't get sent - apparently, I lost my link
around this point, so it stayed waiting for me. I've written a proof
of concept of the above since I penned it...
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/