Peter Memishian wrote: > > Is there anything else that could meaningfully be done with mblk_t data?
Not really, no. As you said, the driver has no idea of the heritage of that mblk_t. > If not, could we just document that the STREAMS framework will reset the > attached mblk to a pristine state prior to invoking free_func(), and save > the driver from rummaging around in private fields? > 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? Paul
