Subject: Re: newfs_msdos
To: None <>
From: Brook Milligan <>
List: tech-userlevel
Date: 12/10/1999 11:17:39
   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).


   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 !


   It could be usefull but it should not be required if informations can be found
   somewhere else or resonable default values provided.


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)

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?

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?