[brussels-dev] Re: [networking-discuss] Brussels high-level design document

[Garrett D'Amore]

sowmini.varadhan at sun.com wrote:
> On (06/22/07 10:26), Garrett D'Amore wrote:
>   
>> Why not have mac_prop_lookup go to the DDI properties on behalf of the 
>> driver?  (In other words, instead of going up to some daemon, if the daemon 
>> isn't present, just use the driver.conf properties.)
>>
>> What I'm getting at is, this detail, can be hidden behind the 
>> mac_prop_lookup() API.
>>     
>
> mac_prop_lookup does not go to the daemon in the current design.
> At the start of attach (or mac_start() -  see 
> http://www.opensolaris.org/jive/thread.jspa?threadID=33043&tstart=0), 
> the handshake between kernel and daemon is done to load up the property
> list in the kernel into a "mac_prop_t" list. After that, when the
> driver does a mac_prop_lookup(), the property is retrieved from the
> kernels mac_prop_t list.
>
> The ddi properties are retrieved by doing file processing in hwc_parse()
> (when  it is called from i_ddi_load_drvconf). So unless we make this
> code parse dladm.conf (which has its own problems, not the least of
> which is that dladm.conf syntax is Private, and can be XML-ed, not to 
> mention that we don't want to be doing some bulky string/file processing
> in the kernel) and load up the mac_prop_t list, the driver code (or the
> underlying mac_prop_lookup) will have to call ddi_prop_lookup to get at
> the property.
>
> But the more fundamental issue is that we still end up with this
> reliance on driver.conf.
>
>   

Yeah, I'm not too thrilled about this.

Configuration of properties for diskless boot is a major PITA. I had a 
different solution for this, which actually _did_ involve parsing 
configuration files (name-value lists) in the kernel. That was how I 
solved it for Tadpole.

>> Btw, I also like Darren's approach of pushing a copy of the
>> properties to
>> the driver.conf (using driver.conf as a secondary store), but I
>> recognize
>> that this has its own set of problems.  (Like the fact that
>> /kernel/drv/xxx.conf might not be on a writable filesystem.)  
>>     
>
> There are others. we now have the unpleasant task of translating something
> like "bge0 default_mtu=9000" to some ugly string that has pci path names 
> in it. And dladm gets to figure out the shibboleth that each
> driver uses for some particular tunable.
>   

No, don't try to have differences for each driver. Just use one common 
name for each ddi property. :-) It will be up to administrators (or 
upgrade scripts!) to adapt to the new names/syntax. :-)

> Which leads me back to the point raised in early discussions that it
> might not make sense to convert every single property to Brussels, esp.
> if the property really cannot be modified on the fly, but is so closely
> related to attach  that it needs all its input at the start of attach.
> i.e., don't reinvent update_drv, if update_drv cannot be avoided.
>   

I would agree that there may be some properties that cannot easily be 
converted.

But I think there are also properties that _can_ be provided by 
Brussels, but which some drivers may not easily be converted.

> --Sowmini
>
>