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

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Thu, Mar 11, 2010 at 10:16 AM, Masao Uebayashi 
<uebayasi%gmail.com@localhost> wrote:
> On Thu, Mar 11, 2010 at 12:13 AM, David Young <dyoung%pobox.com@localhost> 
> wrote:
>> 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.
>
>> 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.

Remember the cost to fix drivers to extract IDs in match().  Now I see
no value doing this.

Masao