On Wed, Mar 10, 2010 at 01:24:40AM +0900, Masao Uebayashi wrote: > > 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> > > Usually GUID is recorded in partition table. You're viewing things in reverse > order...
I don't see a problem. Let the kernel read the partition table, iterate over the partitions, extract properties from each partition, try to match a dk to each partition by properties (e.g., guid(dk3) == guid(partition 7 at sd0)). If there is a match, take the dk unit number from the matching property list (e.g., dk3). If there is no match, choose a unit number that is used by neither a device_t or a configuration properties list. Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 278-3933
