On Wed, Mar 10, 2010 at 01:49:02PM +0900, Masao Uebayashi wrote: > > The code providing DKWEDGE_METHOD_GPT already has the knowledge. I > > don't think that the knowledge has to move from there. All that dk(4) > > has to do is to match device-properties lists, and for that it can use > > the same library function as every other match routine will use. > > What if you want to mount a NIC as /? You'll fix all drivers?
Of course you have to fix drivers. Drivers don't extract the device properties and store them in a standard form, today. > All of you say that lookup-by-ID works in your way. It's possible, > because ID is unique. What I'm talking is the best design how to do > it. Now raidframe(4) alreadys does it itself, why do you have same > logic in raidframe(4) and dk(4)? What do you mean, the same logic? > I think dk(4) does too many things. That means you have to > re-implement same logic in many places. That also means users have to > learn all devices' behavior. Drivers have to know how to extract properties such as MAC address from their devices. I don't think that we can avoid that. If drivers record the properties that they extract under standard keys, then we can match them using a library function. > If you say all drivers behave same way, why do you have multiple > copies of code? I said that there would be a library function. :-) > > The point is to make the device node, /dev/dk3, a reliable handle for > > the volume. > > The point is you can't rely on device unit numbers of pseudo devices. We can discard the pseudo-devices concept, if need be. We cannot rely on any device's unit numbers, now, if it can change slot/port/chassis. If we extend the set of "locators" to include intrinsic device properties such as MAC address, volume GUID, and serial number, then we can establish a permanent correspondence between a device unit and a physical device. Dave -- David Young OJC Technologies [email protected] Urbana, IL * (217) 278-3933
