Peter Memishian writes: > > > 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 :-/
It's a fast-track, so there's no voting (yet), but if we were voting, I'd be opposed to elevating db_mblk. It just can't work well enough to be stable -- you can have multiple mblks that point to the same dblk. It's sometimes useful for examining a dump, but that's about it. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
