From owner-cvs-src@FreeBSD.ORG Sun Oct 10 22:09:32 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E769A16A4CE; Sun, 10 Oct 2004 22:09:32 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29C5343D1F; Sun, 10 Oct 2004 22:09:32 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i9AM9MDI015079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Oct 2004 02:09:22 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i9AM9MZr015078; Mon, 11 Oct 2004 02:09:22 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Mon, 11 Oct 2004 02:09:21 +0400 From: Gleb Smirnoff To: Sam Leffler Message-ID: <20041010220921.GB14849@cell.sick.ru> References: <200410091325.i99DPK00097724@repoman.freebsd.org> <4168009A.303@errno.com> <20041009213710.GB8922@cell.sick.ru> <41686584.6070606@errno.com> <20041010093157.GA11523@cell.sick.ru> <4169AB03.7060105@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4169AB03.7060105@errno.com> User-Agent: Mutt/1.5.6i cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/sys mbuf.h src/sys/kern uipc_mbuf2.c src/share/man/man9 mbuf_tags.9 X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2004 22:09:33 -0000 On Sun, Oct 10, 2004 at 02:34:59PM -0700, Sam Leffler wrote: S> >S> You did not find existing uses of subclassing because I backed out the S> >S> vlan changes to use a private pool for unrelated reasons. I very very S> >S> strongly disagree with this change and want it reverted. S> > S> >This was not broken. Look in my changes to uipc_mbuf2.c, you'll see that S> >m_tag_delete() was changed so that it calls free thru method pointer. S> >As I said, I've checked all m_tag_free() consumers, and nothing is S> >affected. S> S> I'm sorry but one of us does not understand the issues. You changed S> things so that calls to m_tag_free no longer invoked the free method. S> This meant that every such call would do the wrong thing for tags S> allocated using a private strategy. Yes, that's right. S> Because you didn't see any of these S> in the tree does not matter. Your change made it impossible to use S> private allocation strategies. No, see below ... S> In fact with your change there was no S> longer a reason to have a free method in the tag structure. My change does not affect potential private allocators. For example, it does not conflict with if_vlan.c rev. 1.56, which I believe, you use as an example. In if_vlan.c rev. 1.56 you use a private method for free: mtag->m_tag_free = vlan_tag_free; When mbuf is m_freem()d, m_tag_delete() is called from mb_dtor_mbuf(). Notice, that I have changed m_tag_delete() so that it calls private method, and thus vlan_tag_free() will be called. So, I can't understand why do you call it broken. S> >My main purpose for this change was to create a possibility to create a S> >custom S> >free method, which inherits default method. How it is possible to do it S> >now, without API change? S> S> You need to expose the previous _m_tag_free routine so it can be called. S> My only request to you when you did this was to remove the leading '_' S> as the routine was no longer going to be private to the file. What S> seems to have confused you is that you not only need to remove the '_' S> but also choose a different name so that it does not conflict with S> m_tag_free defined in mbuf.h. I thought that was obvious but perhaps it S> was not. OK, if we just rename it to something else, then both approaches will be usable. What do you prefer m_tag_free_default() or m_tag_free1() or smth else? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE