Peter Memishian wrote:
> > Are you suggesting passing the mblk_t as an argument to free_func? The
> > reason that the driver needs to use db_mblk at the moment is that the
> > context argument to free_func is free_arg. In my driver code free_arg
> > points to my own structure. In that structure I store the dblk_t pointer
> > and then I use db_mblk to find the mblk_t pointer. Passing the mblk_t in
> > as an argument is therefore unnecessary for the driver code as it stands.
> > Would it not be reasonable for this case to simply establish the
> > stability of db_mblk at the same level as xesballoc() (or higher) so
> > that drivers using xesballoc() can use db_mblk?
>
> I'm mildly uncomfortable with promoting it since db_mblk is quite hard to
> use correctly and moreover is intended as an implementation artifact
> (indeed, it didn't exist in SVR4's datab). But I don't get a vote on this
> case, and I guess all abstractions are eventually violated in the name of
> performance :-/
>
>
I like the idea of the free_func getting passed a third argument, which
is the mblk_t * associated. Then nobody needs to look at db_mblk. I
confess that I'd also feel better if the framework code reset the mblk
fields to default, so that drivers were not required to know which
fields to change and which not. (The problem is what happens if sizeof
(mblk_t) changes?)
A way to achieve this without requiring a common switch case might be to
add a new function, msgreset() or somesuch, which just clears the
initial mblk header fields to reasonable defaults. Then the free
routine could call msgreset() before reusing the mblk. Thoughts?
-- Garrett
