On Thu, Mar 11, 2010 at 12:13 AM, David Young <dyoung@pobox.com> wrote:
quoted text
> 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

True.

quoted text
> the properties that they extract under standard keys, then we can match
> them using a library function.

OK, you want to match device by ID.  Like:

        fxp* macaddr xx:xx:xx:xx:xx:xx

That might make sense.

What doesn't make sense there is to *fix* device unit number.  Device
unit number will be no longer used after devfs, because we lookup
struct device by either topologically or ID.

quoted text
>> 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. :-)

"A library function" is inacceptable to me.  This is a substantial
design of device(9) API.  This should be a *primitive*.

Device probes, configures, and extracts properties from the real
device.  Just before leaving attach(), it *puts* its ID in a
well-known place so that device(9) can lookup these IDs later.

Anything more than this is inacceptable to me.  autoconf(9) is already
too complex.  I got *huge* frustration to understand it, that's why
I'm sending lots of Engrish mails now.

quoted text
> We can discard the pseudo-devices concept, if need be.

In what sense?

As I explained in the first post, pseudo device is strict definition;
it has no parent in terms of physiical topology.  It may have parents
in terms of components.   I've very carefully investigated those.  I
strictly defferenciate them.  Please re-read the first post in this
thread.

quoted text
> 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

True.

quoted text
> 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.

I wonder if we can assume serial numbers are unique.

And again, device unit is no more.

Masao