[opensolaris-summit] driver limits [was Re: My comments (very subjective) on proposed Summit topics]

[Garrett D'Amore]

James Carlson wrote:
> Alan DuBoff writes:
>   
>> I know you do, and I believe your intentions are quite good. As a case in 
>> point, I know you try to follow the DDI strictly. Sun internal drivers 
>> seem to have been some of the worst offenders of sticking to the DDI.
>>     
>
> You seem to say that as though it were a bad thing.
>
> For drivers that deliver via ON, there's no reason that they need to
> stick to the DDI at all.  All projects integrating in ON (including
> drivers) are able to use ON consolidation private interfaces without
> additional review.  It's one of the perks of delivering synchronously
> with ON.
>
> The only considerations that matter here are the usual ones, such as
> design correctness and code clarity.  Adherence to rules that apply
> for non-ON code isn't part of the bargain.
>
> I agree that when driver designs are required to reach outside of the
> DDI on a regular basis, then that signals a problem.  It most often
> signals a problem with the DDI: it means that the functions that the
> designers need are not present.  It rarely (though perhaps
> occasionally) means that the driver writer is doing the wrong thing.
>
> So, case in point, the GLDv3/Nemo interfaces are not part of the DDI.
> Many of our drivers use them anyway.  If someone proposed to add a new
> Ethernet driver to ON, and that driver used only DDI interfaces (thus
> ignoring Nemo), I would certainly consider the driver to be defective.
>
> Thus, DDI isn't a mandate.
>   

Historically, believe I had the only DDI complaint ethernet drivers that 
were to be found... either inside ON or outside of ON.  I believe that 
this signaled both deficiencies in ON, and in the various unbundled drivers.

I believe that sticking to the DDI, while not a hard requirement for 
drivers in ON, is a worthwhile cause even for the drivers in ON.

1) It reduces the pain and suffering when non-DDI interfaces change
2) By sticking to documented APIs (or APIs you expect to be documented) 
you're unlikely to be bitten later by changes in undocumented behavior.
3) By using the DDI, you know that you're using the same APIs that we 
recommend to external developers.  That means you help to uncover any 
limitations in the DDI.

I think if the drivers in ON "had" to use the DDI or go thru the process 
of getting a waiver/contract, then its likely the DDI would be a lot 
richer than it is today.  (For one, we'd probably have a public API for 
nexus drivers!)

Note that for APIs like GLDv3, kEF, etc.  I think use is appropriate... 
largely because we are using those APIs as we expect an external 
consumer would, and we're in the process of trying to make them public.  
This is quite different than drivers that start up their own kernel 
threads, etc.

    -- Garrett