Messages in this thread | | | From | Willy Tarreau <> | Subject | Re: KMSGDUMP: dump kernel messages to a diskette | Date | Mon, 5 Jul 1999 08:55:24 +0200 (CEST) |
| |
> Hi Willy.
Hi Riley !
> > - 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... > > > 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. .../...
didn't untar it yet, but this sounds interesting...
> > > 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...
this is right. OTOH, I'd like to keep the assembler code tiny. At the moment, it's nearly 2kB in the last release (you can consult messages on screen, scroll up/down, export them to a printer, choose printer, drive and format, and of course save to the floppy). Linus once said to me that it wasn't good to add lots of assembler code to the kernel because people can't maintain it easily. Moreover, I have some difficulties at merging 16-bits code with 32-bits ; to avoid these issues, I have to make all addresses relative to the begining of the code, which makes it awful ! I'm nearly about to get back to as86 instead of gas, and to write a tool to generate a .c file from the binary. I've looked at "build.c" in the kernel tree and "tools.c" from dosemu. They're both interesting, but don't exactly meet my needs, so I think the better choice will be to convert the "kmsgdump.o" to "static char ..." in a new "kmsgdump.c".
Once I get all this fixed, I'll investigate more into all possibilities that FAT offers, keeping compatibility with DOS (eg: DOS doesn't support a number of FATs different than 2).
I was once asked to reserve some space on an EXT2 FS, and use an absolute pointer to it as a dump offset. Although this might allow to read messages from a running kernel without a diskette, risks of FS corruption scares me. What about CHS/LBA, bios driver numbering ? and if the file is moved/deleted... Or we could mark the file as "immutable" at the EXT2 level, but I find this risky too.
I think that at first, I'll focus on the new release, and not much more. Later, I'll see what people think they really need after they used it.
> > Best wishes from Riley. >
Regards, Willy
- 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/
| |