Replaying a 12 May 2005 mail :-)

> [Freedos-kernel] Analysis: Support for sector sizes != 512 bytes

Hi, I have browsed the CVS kernel a bit, and got the impression
that it would not be too hard to support sector sizes below 512
bytes (32, 64, 128 and 256 bytes should be possible). For sector
sizes above 512 bytes (e.g. 1024 and 2048), each element in
BUFFERS and the DiskTransferBuffer would have to be bigger. Are
there DOS versions which support big sectors? How do they solve
the buffering problem? I think sector sizes below 64 bytes cannot
contain enough of a BPB to be useful. Sector sizes below 32 bytes
are definitely not useful, not even a single dirent fits in them.
Sector sizes above 512 bytes are at most useful for the 1024 byte
(far-east 1.2 MB diskette format / drives which support full 64 MB
of a single XMS2 handle as ramdisk without having to support the
DOS3.x+ 32bit sector number calls) and 2048 byte (raw sector size
on CD-ROM and maybe on magneto-optical drives) cases.

Comments about useful sector sizes would be welcome:
Smaller (64, 128, 256), normal 512, Bigger (1024, 2048, others).

Next part: I believe that the BIOS / kernel drives (diskette,
harddisk) only have to handle 512 bytes per sector. Otherwise,
you would have to adjust: CalculateFATData, DosDefinePartitions,
the kernel driver IOCTLS (e.g. "format track"), LBA_Transfer,
max_transfer (the DMA wrap checker) and maybe floppy_bpb (and -_bpbs).

In case you have wondered, directory handling already reads the
current sector size from the BPB, so it is flexible.
If you want drives with bigger sectors to be detected at boot time,
you not only have to get BUFFERs and DiskTransferBuffer bigger and
adjust _maxbksize (in the global SDA data structure, which is, by
the way, not yet read by FreeDOS itself, as only 512 bytes per sector
are supported anyway) but you also have to make InitDiskTransferBuffer
bigger as well.

For boot purposes you just have to make SYS able to pad unused parts
of the boot sector to allow bigger sector sizes - BUT you also have
to make SYS able to adjust the boot sector code to that, I remember
that not all our boot sectors actually used the BPB bytes-per-sector
value (there was not enough space to process it). Smaller sector sizes
are simply too small to be bootable anyway. I wonder if you should be
able to boot from nonstandard sector sizes at all - for example a CD-
ROM does not even have a FAT filesystem, so why would you boot from a
(raw!) CD-ROM then?

So I suggest to support nonstandard sector sizes ONLY for drives which
are connected to separate drivers (e.g. ramdisks, USB drives, ZIP...).
To make that possible, BUFFERS and DiskTransferBuffer handling would
have to get better (even for smaller sectors - for bigger sectors, the
BUFFERS and DiskTransferBuffers themselves, being only _maxbksize big,
will be the problem).
In addition, getbpb and dskxfer (THE central "send/receive a sector to/
from a device driver" function) have to be made independent from the
hardcoded SEC_SIZE. Instead, they have to use the sector size from the
BPB of the drive. Hint: getbpb assumes that the boot sector magic word
is at offsets 1fe and 1ff. This IMPLIES a sector size of 512 bytes, too.
The GOOD part is that FreeDOS hardly uses anything else than getbpb and
dskxfer to communicate disk contents (for which it uses BUFFERS and
DiskTransferBuffer as intermediate storage places). rqblockio does call
block device drivers directly, too, but not to access sectors, for
example, and the other functions all use dskxfer or getbpb directly or

I hope I have not overlooked things in this review... Summary:
- To support bigger sectors, raise _maxbksize and make each element
  of BUFFERS and DiskTransferBuffer bigger
- To support nonstandard sector sizes at boot time, CalculateFATData,
  InitDiskTransferBuffer and DosDefinePartitions have to be modified
- To support nonstandard sector sizes for harddisk / diskette (kernel
  built-in drivers), you have to adjust the IOCTLs (format track...),
  LBA_Transfer and max_transfer
- To support nonstandard sector sizes at all, you have to modify
  dskxfer and getbpb and the BUFFERS and DiskTransferBuffer handling
  has to accept sectors in other sizes than SEC_SIZE, including e.g.
  sectors which are smaller than _maxbksize...
- SYS and boot sectors can only support bigger, not smaller, sector
  sizes, and SYS might have to do extra patching for those of the boot
  sectors which do not actually use the boot sector BPB sector size info

We should probably start by using _maxbksize in BUFFERS and either only
DiskTransferBuffer or both DiskTransferBuffer and InitDiskTransferBuffer
to get things a bit clearer... Then we should make SYS and boot sectors
able to support bigger sector sizes (not because it is really useful but
because this part is more self-contained / easier to maintain than the
rest of the kernel).

Then the first WORKING support for nonstandard sector sizes can be
added by making BUFFERS and DiskTransferBuffer handling aware of the
CURRENT sector size and making dskxfer and getbpb able to support
all of the sane (64, 128, 256, 512, 1024, 2048 bytes) sector sizes
and aware of the current sector size.

Only as a bonus step we could modify the kernel drivers and IOCTLs to
support nonstandard sector sizes for harddisks and diskettes. See above.

Please comment. Only having to modify 2 buffering systems, 1 variable
and 2 core disk access functions to get support for RAM / ZIP / USB
drives with nonstandard sector sizes somehow sounds too good to be true.
Support for booting big-sector drives and for nonstandard-sector-size-
harddisks and diskettes would be an extra but probably not too useful?

Thanks for your comments! Trying to wake up the kernel list a bit :-)).


PS: If there are no comments, conserve this as technote and wait for
comments from reappearing or new kernel people in the future... But I
think that there ARE still people around here (as opposed to the fd-doc-
list, freedos-devel-net and freedos-freecom: I really recommend to move
the remaining members to freedos-user and freedos-devel to get out of
the current "frozen" state in which only from time to time somebody pops
up, asks a question, and gets no answer on doc-list, devel-net, freecom).

RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
Freedos-kernel mailing list

Reply via email to