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