James Carlson wrote:
>> I agree that one cannot make arbitrary use of db_mblk since in the
>> general case it will point to only one of many mblk_ts that may be
>> linked to the dblk_t. However, in the case of the free_func(), db_ref is
>> guaranteed to be 1 so db_mblk always points at the one and only mblk_t.
>
> I've never viewed that as a serious limitation. You can always
> arrange things such that the free_arg is either a structure containing
> a pointer to the mblk_t or is just the mblk_t itself.
>
Actually that's exactly what you *shouldn't* do, which was the point of
the note in the first place. When free_func() is called the original
mblk_t may have *already* been freed (e.g. dupb; freeb) so you should
not follow any references to it. The dblk_t pointer is always safe
because it is never freed until after free_func() is called.
>> If the general preference is to have the mblk_t passed as an argument to
>> free_func() then I'm not necessarily against it; I just think it's
>> slightly pointless in this circumstance.
>
> I think the uncomfortable part is that it forever nails down the
> structure offset and functional behavior for db_mblk, because we can't
> predict who might be using it.
>
I think it's overkill here since xesballoc() is only supposed to be
consolidation private but I have no problem with the mblk_t being passed
as an argument. I'll modify my prototype code accordingly.
Paul
--
=========================================================
Paul Durrant SolarFlare Communications
Senior Staff Engineer Block 2, 2nd Floor
TEL: +44 (0)1223 518040 Westbrook Centre
FAX: +44 (0)1223 464225 Milton Road
Cambridge, CB4 1YG
UK
=========================================================
