cvs commit: src/sys/sys mbuf.h src/sys/kern uipc_mbuf2.c src/share/man/man9 mbuf_tags.9

[Sam Leffler]

Gleb Smirnoff wrote:
>   Sam, 
> 
> The change is reverted.

Thank you.

> 
> On Sat, Oct 09, 2004 at 03:26:12PM -0700, Sam Leffler wrote:
> S> 1. You changed this without discussion.
> S> 2. It breaks the intentional purpose of subclassing the m_tag_free method.
> S> 3. Openbsd compatibility is not broken by calling through the method 
> S> pointer; in fact calling through the method pointer is required to 
> S> maintain compatbility (think about it).
> 
> It is broken since in OpenBSD and FreeBSD function with same name do
> different things.

In case you haven't noticed there are many differences between openbsd 
and freebsd--openbsd lags behind freebsd  in supporting tags.  As to 
functions with the same name doing different things; this is not 
correct; m_tag_free reclaims the resources associated with a tag.  On 
freebsd this is done by calling through the method pointer so private 
allocation strategies can be used.  Openbsd has nothing similar (as of 
my last check), it's m_tag_free routine simple free's the storage.

Perhaps you were not aware that I brought the tags support over from 
openbsd and I made the effort to insure compatibility.  I believe I have 
a reasonable understanding of this issue.
> 
> S> You did not find existing uses of subclassing because I backed out the 
> S> vlan changes to use a private pool for unrelated reasons. I very very 
> S> strongly disagree with this change and want it reverted.
> 
> This was not broken. Look in my changes to uipc_mbuf2.c, you'll see that
> m_tag_delete() was changed so that it calls free thru method pointer.
> As I said, I've checked all m_tag_free() consumers, and nothing is affected.

I'm sorry but one of us does not understand the issues.  You changed 
things so that calls to m_tag_free no longer invoked the free method. 
This meant that every such call would do the wrong thing for tags 
allocated using a private strategy.  Because you didn't see any of these 
in the tree does not matter.  Your change made it impossible to use 
private allocation strategies.  In fact with your change there was no 
longer a reason to have a free method in the tag structure.
> 
> My main purpose for this change was to create a possibility to create a custom
> free method, which inherits default method. How it is possible to do it
> now, without API change?
> 

You need to expose the previous _m_tag_free routine so it can be called. 
  My only request to you when you did this was to remove the leading '_' 
as the routine was no longer going to be private to the file.  What 
seems to have confused you is that you not only need to remove the '_' 
but also choose a different name so that it does not conflict with 
m_tag_free defined in mbuf.h.  I thought that was obvious but perhaps it 
was not.

	Sam