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/