Re: (Semi-random) thoughts on device tree structure and devfs

[David Young <dyoung%pobox.com@localhost>]

On Tue, Mar 09, 2010 at 08:09:57AM +0000, Iain Hibbert wrote:
> On Mon, 8 Mar 2010, David Young wrote:
> 
> > On Mon, Mar 08, 2010 at 12:34:23PM -0700, Ted Lemon wrote:
> > > On Mar 8, 2010, at 12:47 AM, Masao Uebayashi wrote:
> > > > How do you write a kernel config which can always identify my USB disk 
> > > > as
> > > > sd0a, even if I plug random devices?
> > >
> > > You'd need to put the UUID in the kernel config.
> >
> > I'd go further and say that we should be able to supply a set of device
> > properties (such as drvctl -p prints) to the kernel.  Let us match a
> > device by its intrinsic properties (MAC address, serial number, and/or
> > GUID), and set the unit number according to the device property.
> >
> > Quentin is right that this *only* helps us to fix the unit number, but I
> > think that in itself is an important, *feasible* step forward.
> 
> One thing that I think is problematic about trying to do that, is that you
> might sometimes need to attach a device (allocate the unit number) in
> order to discover its intrinsic properties. It can't always be done in the
> attach routine because you might have to wait for a query (or several) to
> return. For that reason, we should consider that the dv_xname is not
> necessarily a useful tag.
>
> (I say "device" rather than disk because I know that Bluetooth controllers
> work this way - you can't get the BDADDR until it is up and running)

I don't understand why the intrinsic properties cannot be found out in
the match routine, or why waiting for several queries is a problem.

> I have never used wedges but, for the disk case, would it not be better to
> make a method of configuring a dk in advance, so that whenever a disk
> appears with the correct parameters it will already be mapped to the dk
> you expect? (perhaps a daemon could handle it) Then you know that /dev/dk3
> is your USB stick and will never be anything else..

We don't need a second mechanism to handle dk(4), do we?  If dk3 should
attach to the volume with GUID 60708090-a0b0-c0d0-e0f0-01020304050, let
the device properties say so:

<plist version="1.0">
<dict>
        <key>device-driver</key>
        <string>dk</string>
        <key>device-unit</key>
        <integer>0x3</integer>
        <key>guid</key>
        <string>60708090-a0b0-c0d0-e0f0-01020304050</string>
</dict>
</plist>

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933