Hi,

> Well, information like sectors per cluster, a drive number, number of
> root directory entries, ... .  Perhaps you used command line swithces
> for mformat to set these?  Perhaps the data come from within the
> program as compiled in defaults?  I don't know exactly how you
> manipulated mformat.  The point is that the BIOS parameter block needs
> stuff besides the geometry; see any technical document that describes
> the layout of a MS-DOS bootsector.  Command line switches could be
> given to set these, but it also seems reasonable to include this in
> whatever table describes the floppy parameters (compiled in or
> otherwise).
> 
> A compiled in table will certainly work, but allows for no extensions
> except by recompiling.  Use of /etc/floppytab allows for extensions to
> new types of disks.  That seems preferable to me, since it "makes
> sense" (to me, anyway; in essense we are talking about parameters
> describing floppies after all), it does not interfere with the only
> other program that uses that file, it allows for greater flexibility,
> and we have the file anyway for only a slightly different purpose.

Hmm, since your proposed version of newfs_msdos will be used to format
harddisk partitions, too, I think that there should be some builtin
mechanism that determines those numbers from the information that is
available for the partition (i.e. information found in the MBR).

Whether or not there is a possibility to overwrite this via entries in
/etc/floppytab and/or command line parameters is a different question
(and for the record, I'm all for it).

However, IMHO it's not very friendly to require the user to first setup
an entry in /etc/floppytab before he can call newfs_msdos for his partition.

[ This is from another mail by Manuel: ]

>    I'm sure all the infos are here (we tell to tell fdisk the geometry,
>    and can print it back when re-reading the partition table). 
>    The table would still be needed for floppies though ...

No, the MBR doesn't contain any explicit geometry information.  What
fdisk prints out as the BIOS geometry is just the values it deduces
from comparing the absolute offsets/sizes against the cylinder/head/sector
information.

You'll note that for empty MBR partition tables, the geometry information
that fdisk tells you matches the parameters extracted from the in-core
disklabel, and that changing the BIOS geometry with fdisk will not stick
(well, at least if you don't do any other changes to the MBR; if you
create a new partition with the changed geometry, there is the possibility
that fdisk will take the information from this new partition to deduce
the BIOS geometry, but I don't know what happens, if there are partitions
in the MBR with different ideas of the geometry).

[ Back to Brook's mail: ]

> Overall, I'm unclear about your message.  Is it that there is no need
> for an enhanced newfs_msdos?  Is it that /etc/floppytab should not be
> used as a table to contain the information needed?  Is it that this is
> a good idea but you'd like to see information in the disklabel used if
> possible?  Or is it something else?  There is no point in continuing
> if the message is the first?  I'm asking these questions, after all,
> so that the final version will be accepted into the tree.

I certainly think that there is a "need for an enhanced newfs_msdos".
However, as I said above, the information needed should be extracted
from the geometry information available from the disk itself.  And the
additional values should get reasonable defaults based on the size etc.
of the partition.  Just like you can do a newfs for a ffs partition
without entering a lot of parameters.

Just my 0.02 euro cents.

Ciao,
Wolfgang
-- 
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800