Subject: Re: newfs_msdos
To: Brook Milligan <firstname.lastname@example.org>
From: Manuel Bouyer <email@example.com>
Date: 12/11/1999 03:42:20
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).
> 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?
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 <firstname.lastname@example.org>