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
