Date: Thu, 24 Sep 1998 16:52:44 -0400 From: David Holland <dholland@cs.toronto.edu> To: peter@netplex.com.au (Peter Wemm) Cc: bright@hotjobs.com, current@FreeBSD.ORG Subject: Re: Current is Really Broken(tm) Message-ID: <98Sep24.165248edt.37912-17305@qew.cs.toronto.edu> In-Reply-To: <199809231124.TAA14644@spinner.netplex.com.au> from "Peter Wemm" at Sep 23, 98 07:24:39 am
next in thread | previous in thread | raw e-mail | index | archive | help
> The problem is that DEVFS doesn't know if /dev/wd1s1e (for example) exists
> until the disklabel is read. The disk label isn't read until the device
> is opened. To open the device, you have to read the /dev/wd1s1e node..
> Catch-22. (Opening /dev/wd1s1 also causes the disklabel to be read, but
> that's not the name of the device in /etc/fstab)
>
> One way around it is to simply have DEVFS create all possible nodes for
> slices and partitions regardless of whether or not they exist. This is
> probably a step backwards though.
My perspective on this is that disklabels and partitions are a
protozoic kind of file system -- essentially, that the way to think
about what needs to happen is that you need to mount `partitionfs' on
the device /dev/wd0. This `mount' then supplies the other wd0* devices.
(Whether it goes through the same code path as normal filesystem
mounts, or looks at all like them, is unimportant. Bear with me.)
This view of the world has two immediate consequences:
1) partition handling should be independent from disk drivers.
2) probing for partitions becomes relatively straightforward.
I claim that (1) becomes more true the more distinct kinds of
partitioning information and disklabels you have floating around. I'm
also not aware of any common disk hardware that has custom
partitioning information or idiosyncratic placement of normal
information.
(2) follows because the probing takes place in the `mount' of the
`partitionfs' on the particular disk device. Once you think of it as a
mount, and not a probe, you start making the right assumptions about
when and how it should happen, or at least I do. Namely, the root
disk's partitions need to be established right before the root
filesystem is mounted, and the rest can and should wait and be done
via fstab or some equivalent.
Whether it's safe to iterate over all the existing disk devices and
try to `mount' partitions on them or not depends on how many types of
partition data you're likely to run into, how likely it is to mistake
something that isn't for a disklabel, and so forth. That is, it's
probably safe and should be done right before mounting root by taking
an inventory of all disk devices found on the system.
--------
Another way to look at it is as follows:
What you'd like to have happen is automatically have everything load
up and probe when someone touches /dev/wd0s1e. This is essentially
demand loading of devices. Was DEVFS designed to allow this? I'm
guessing that it wasn't, since if it was this probably wouldn't be an
issue.
Having built a virtual /dev filesystem that *was* meant to support
both demand loading and only listing existing devices, I can say with
some degree of certainty that you can't kludge demand loading in:
there's a fundamental contradiction between the two features, in that
you can't demand load something you don't know exists, but you
typically have to load it to discover whether it exists or not.
The solution I eventually came to in VINO (1) was to have something
akin to the kernel config file specify what device nodes existed and
bind them to drivers that would be loaded on the fly when used. For
various reasons this is only at most half done, and it hasn't yet been
tried with drivers that require a significant amount of probing, so I
don't have a whole lot of confidence in it at this point.
The config file entries for a disk might look something like this:
wdc0 wdc-driver [irq/port type of information]
wd0 wd-driver wdc0 0
wd1 wd-driver wdc0 1
wd0a bsd-partitions wd1 0
wd0b bsd-partitions wd1 1
wd0c bsd-partitions wd1 2
:
The first column is the name in /dev, the second column the name of
the device driver, and the rest are arguments, typically a device to
mount on top of and a unit number. The names in /dev are generated by
the vino devfs code, which auto-loads the driver and opens it, passing
the arguments, when the name is referenced.
(This junk is parsed on the fly by the kernel. VINO is a pretty
heavyweight kernel in a lot of ways; I'm not recommending this for
FreeBSD, just attempting to illustrate my example completely.)
Anyway, this is all pretty much just blathering as I haven't looked at
the FreeBSD DEVFS code in a long time. :-)
(1) http://www.eecs.harvard.edu/vino/vino, although there isn't much
about the devfs on the web pages.
--
- David A. Holland | (please continue to send non-list mail to
dholland@cs.utoronto.ca | dholland@hcs.harvard.edu. yes, I moved.)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?98Sep24.165248edt.37912-17305>