>>> - 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...
For reference, here's the details of what it uses on a 1440k floppy:
Q> Boot block: 1 sector
Q> FAT size: 2 sectors each
Q> Root directory: 3 sectors, giving 48 entries
Q> Data area: 359 clusters of 4k each, totalling 1436k
This results in the first 4k of the disk being the ONLY overhead
thereon, and the remainder of the disk being the 1436k data area for
users to put files on. As comparison, here's the figures for the other
cluster sizes of relevance on a 1440k diskette with 2 FAT's:
Q> Sectors/Cluster: 1 2 4 8 16 32
Q> FAT Entries: 2860 1434 718 359 179 89
Q> Boot block: 1 1 1 1 1 1
Q> FAT #1: 9 5 3 2 1 1
Q> FAT #2: 9 5 3 2 1 1
Q> Root Directory: 1 1 1 3 13 29
Q> Data Capacity: 1430k 1434k 1436k 1436k 1432k 1424k
Now, the figures with 1 FAT:
Q> Sectors/Cluster: 1 2 4 8 16 32
Q> FAT Entries: 2868 1434 718 359 179 89
Q> Boot block: 1 1 1 1 1 1
Q> FAT: 9 5 3 2 1 1
Q> Root Directory: 2 2 4 5 14 30
Q> Data Capacity: 1434k 1436k 1436k 1436k 1432k 1424k
As can be clearly seen, only the capacities for 1 or 2 sectors per
cluster changes, and in both cases, the optimum capacity remains at
1436k per diskette, so there's no advantage in moving to just 1 FAT.
There's certainly no advantage in moving to more than 2 FAT's either.
>>> 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.
That's true in general, but there are occasions where it's needed.
However, one way to minimise the assembly requirements might be to
have the C code create the disk image in memory, with the boot sector,
both FAT's, the root directory and the data area, then call a routine
that switches to real mode, writes the data out to the first floppy,
and reboots if that option is called.
> 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 can certainly understand that...
> 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".
Probably...
> 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).
If you analyse the diskettes that could be available, you'll soon see
that such isn't a problem. Here's my quick analysis...
1. Irrespective of their other dimensions, ALL standard 3.5" and
5.25" floppy formats involve the use of a multiple of 8 tracks
(either 40 or 80 tracks occur, both being multiples of 8), so
ANY format, irrespective of sector size, sectors per track or
anything like that, will also result in the total number of
sectors on the disk being a multiple of 8.
2. FAT mandates the use of 512 byte sectors, grouped in clusters
that occupy a number of sectors that is an exact power of 2.
The valid values are 1, 2, 4, 8, 16, 32, 64 and 128 sectors
per cluster.
The direct implication of that combination is that ANY formatting
scheme that is FAT compatible, and involves not more than 8 sectors
per cluster, will require that the overhead space at the beginning of
the disk, plus any unused space at the end of the disk, total an exact
number of clusters.
In the case of the format mentioned above, that overhead space
occupies exactly ONE cluster, which is the minimum it can occupy, and
ALL of it is used - there are no unused sectors on the disk at all. As
a result, the ONLY difference resulting from decreasing the number of
FAT's is to increase either the size of the root directory (and thus
the number of entries it can hold), or increase the amount of unused
space on the disk, and neither benefits the intended application.
> 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 don't know who thought that idea up, but it really stinks! Even if
you included that facility, I'd make sure it was disabled for
precicely the reason mentioned...
> 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.
One thought: The main objection to the idea of dumpiing to disk has
been in connection with the fact that at the time the dump is needed,
it might not be possible to get reliable details as to where to put it
on the disk. To me, the obvious answer to that is to have the dump
driver hold a local pointer to the relevant location, initialise it at
system boot, and have hooks in the mount and sync routines to ensure
it's still valid.
Comments?
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/