On Fri, Dec 10, 1999 at 11:17:39AM -0700, Brook Milligan wrote:
>    I just created a /etc/mtools.conf with:
> 
>    This is because I can't just tell mformat /dev/rwd0a (I'd expect to be able to
>    do this with newfs_msdos).
> 
> Exactly.
> 
>    I guess mfomat just has reasonable defaults for other values. You can't
>    select them with MSDOS's format anyway :)
> 
> Reasonable defaults will be used.  My suggestion with /etc/floppytab
> was a way to alter those defaults in a persistent manner without
> recompiling.  Just because MS doesn't give access to all the
> components, doesn't mean that a properly designed tool should do the
> same. :)
> 
>    For sure not, I'd like to see it !
> 
> Good.
> 
>    It could be usefull but it should not be required if informations can be found
>    somewhere else or resonable default values provided.
> 
> Exactly.
> 
> So I think the consensus is this:
> 
> - command line switches override anything and allow choosing an entry
>   from an enhanced /etc/floppytab or tweaking anything individually
> 
> - if possible (and not otherwise specified) get information from the
>   following, proceeding until something works:
> 
>     - BIOS information (via sysctl(), ala fdisk)
>     - inferred from MBR (also ala fdisk)
>     - from in-core disklabel
>     - punt
> 
> - for whatever geometry entry is identified, choose reasonable
>   defaults (dependent on geometry) for everything else (unless
>   overridden by command line)

Looks good.

> 
> The only issue I'm not really familiar with is matching the
> information from the kernel (obtained by sysctl()) or from the
> disklabel (obtained by ioctl()) with the device file (e.g.,
> /dev/rwd0h) to write to.  For the disklabel, I guess I can assume that
> we aren't looking at any links and take the last letter as the index
> into the partition table returned by ioctl().  This isn't foolproof if
> people create links and call newfs_msdos with the other names, but
> perhaps that isn't our problem and the names given could be checked to
> fall within certain patterns.  What about for the information returned
> by sysctl()?  Any suggestions for these issues?

For sysctl, I think fdisk does this already, doesn't it ?
I don't know exactly what this sysctl does but I think it returns the
drive name (e.g. wd0) as well.

> 
> Finally, if newfs_msdos and fdisk start using the same code would it
> make sense to put it into some common library or is that premature?
> What would be the best design for doing that?

Sure it should !

--
Manuel Bouyer <bouyer@antioche.eu.org>
--