On (06/20/07 19:50), Garrett D'Amore wrote:
>>
>> I'd rather see those things left behind whereever they are -- ndd,
>> driver.conf -- and left out of Brussels user interfaces, with bugs
>> filed to have them removed completely over time.
>>   
>
> One quick note on this theory.  I do not want to leave them "where they 
> are" (if that is in ndd), if that means that old device drivers have to 
> retain all the crufty ndd logic _in addition_ to implementing the new 
> Brussels API.

right. The ndd programming interface is completely obscure, and the
real problem here is in the design itself - as Garrett pointed out,
the correct solution is for the DLD framework to address many parameters
like  the bcopy/dma/interrupt related  issues. 

I think that using private properties, with clear caveats indicating
that this will be replaced by other methods, is the cleaner solution here.
In its defense it is better documented, and simpler to trace, than ndd.
Yes, it can be abused, but those seeking its abuse will find uglier
implementation ways via ndd. Besides, there are some driver developers
who have asked for something like this: as Drew points out in
http://www.opensolaris.org/jive/thread.jspa?threadID=25400&tstart=75

> One of the things I don't like about the linux "ethtool" is the
> inability to set "custom" parameters. Eg, it will let you set
> only parameters which are common among many drivers. If you've got
> something specific to your driver (mydriver.fluxcapacitor) you
> cannot change it. 

--Sowmini



Reply via email to