[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-code
Subject:    Re: [osol-code] Thoughts on changes to DDI entry points for drivers
From:       Darren Reed <Darren.Reed () Sun ! COM>
Date:       2009-04-09 21:38:30
Message-ID: 49DE6AD6.8040905 () Sun ! COM
[Download RAW message or body]

On  9/04/09 09:41 AM, Garrett D'Amore wrote:
> Paul Durrant wrote:
>> Garrett D'Amore wrote:
>>>
>>> I'm unconvinced that it is any cheaper.  The question is ... how is 
>>> the kernel DDI going to track these by dev_t.  dev_ts  don't point 
>>> to structures.  So the DDI implementation would either need to use a 
>>> hash table itself, or would need to manage to track the state 
>>> elsewhere, and I'm just not sure where it would be tracked.   We 
>>> need more information about the proposed underlying implementation, 
>>> I think.
>>>
>>
>> The DDI doesn't have to track anything. The dev_ts are managed by 
>> specfs which has access to the underlying vnode or snode - hence my 
>> comment about stashing the context pointer there.
>>
>>   Paul
>>
> In this case, yes, sparing the table lookups would indeed be faster.

My thoughts were that the context pointer would be stashed in a 
structure "behind the scenes" so that there was no table lookup and no 
table to maintain. In contrast, if there is a "ddi_set_devt_private()", 
then some new table needs to be created and managed, adding with it new 
complexities of synchronised access, etc. The idea was for it to be 
cheap and easy.

Is bumping CB_REV even necessary?

For example, if an old driver is passed "&context" and "context" is 
initialised to NULL, then in all the other entry points, it will be NULL 
and none of the code will ever expect to use it. There should be no 
scope for harmful action.

For new drivers, if they change "context" then they'll get it passed 
back to them and be able to handle it. The only code in the framework 
that should really do anything is for close - that should verify the 
context pointer is cleared by the close(9e) driver function.

I'm not sure that I see any real need to bump CB_REV - am I missing 
something?

This idea is pretty much very doughy at the moment, and still needs some 
kneading before it is ready to bake.

With respect to the many-opens vs 1 close, there's nothing that compels 
a programmer to call kmem_free() after doing a kmem_alloc() if they're 
not worried about running out of memory. At this point in time, I don't 
have a good answer to someone's open(9e) storing something in the 
context pointer for at the many-open case, except to add an ASSERT that 
says "if you don't create a new dev_t then you're not allowed to 
change/set the context pointer." Which is to say that the context 
pointer is there to support the 1:1 programming paradigm for drivers 
that create new devices and if the programmer mixes it up, there's not 
much that can be done?

Darren

_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
[prev in list] [next in list] [prev in thread] [next in thread]