Re: Generic Kernel API

On Wed, 9 Nov 2005, Mark Linimon wrote:

> On Wed, Nov 09, 2005 at 12:20:14PM +0000, Robert Watson wrote:
>> My hope is that in the next year or so, things will settle down
>> significantly as we begin to flush the last of the non-MPSAFE drivers
>> from the system, and reach a point where all device drivers can use
>> consistent synchronization.
>
> If we are working towards that, I'd like to see someone contact the 
> suppliers of the binary-only drivers and tell them that's where we're 
> heading.  IMHO we are starting to win back some 'mind-share' out there 
> in the real world with 6.0 and we should build on that momentum.

I think the first step is to figure out what we're doing.  In the past, 
we've tried to offer relative API/ABI stability across minor releases for 
two classes of device drivers:

- Network interface device drivers
- Storage device drivers

However, we've not made a formal effort to decide what APIs are "safe" for 
device driver vendors to use, and only in the 5/6 time frame have we 
attempted to start hardening the APIs so as to make it possible to keep 
evolving the implementation in a branch without breaking device drivers. 
Some work needs to be done up front to survey what APIs and ABIs device 
drivers currently use, or use indirectly -- things like which data 
structures they depend on for stability (offset of fields in struct 
thread?), which symbols they depend on, what structures they embed 
(meaning we need to preserve size, not just layout) in the stack or their 
own data structures.  In 6.x, with ifnet no longer being embedded in 
device driver data structures, we've improved quite a bit.  In the 
developer summit session on the topic, I'm proposing we identify 
depenendencies of network device drivers, and then discuss where to 
harden, where to hide, and so on.  We won't get it entirely right the 
first time, but I think a bit of investigation and a bit of cleanup will 
go a long way.  Fortunately, we have a pretty good sampling of network 
device drivers in our tree already to look at.

Robert N M Watson