Date: Fri, 26 Oct 2001 09:28:40 -0700 From: Luigi Rizzo <rizzo@aciri.org> To: Bosko Milekic <bmilekic@technokratis.com> Cc: "Keiichi SHIMA / ?$BEg7D0l?(B" <keiichi@iij.ad.jp>, David Malone <dwmalone@maths.tcd.ie>, Alfred Perlstein <bright@mu.org>, net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <20011026092840.F64631@iguana.aciri.org> In-Reply-To: <20011026121724.A21512@technokratis.com> References: <20011023110307.A34494@iguana.aciri.org> <20011023132813.I15052@elvis.mu.org> <20011023114650.C34494@iguana.aciri.org> <20011023140034.M15052@elvis.mu.org> <20011023140628.A36095@iguana.aciri.org> <20011023185759.A328@technokratis.com> <20011026110635.B14635@walton.maths.tcd.ie> <86u1wmlj1s.wl@keiichi01.osaka.iij.ad.jp> <20011026121724.A21512@technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bosko, Keiichi has a valid point. The semantics of an interface are described by the documentation associated with it, not by its name or the Oxford Dictionary. As much as it might be misleading that M_LEADINGSPACE checks for writability, it has probably been like this for a long time, we have plenty of code that depends on this, and people looking for documentation will likely see this behaviour documented. Changing it might introduce insidious bugs in the code -- because in reality, clusters are almost never shared except for those on the TCP send queue and for multicast packets (but who uses multicast, anyways), so there is a chance that we will have buggy code that goes unnoticed for a long time. cheers luigi On Fri, Oct 26, 2001 at 12:17:24PM -0400, Bosko Milekic wrote: > On Fri, Oct 26, 2001 at 08:47:27PM +0900, Keiichi SHIMA / ?$BEg7D0l?(B wrote: > > Right. And we will have a problem if someone changes the semantics of > > M_LEADINGSPACE. The M_LEADINGSPACE macro of Net/OpenBSD does the same ... > > But, I disagree the later proposal from Bosko that changes the meaning > > of M_LEADINGSPACE. This leads more ifdefs in the shared code > > (ex. KAME, maybe other cross-platform projects) and the code > > complexity. > > Just because M_LEADINGSPACE may be broken in the other systems does > not mean that it should be broken in our system as well. I am against > sacrificying good code in order to deal with the left-over stupidities > (pardon the seemingly harsh vocabulary) in the other systems, when it > comes to porting. > You should understand that M_LEADINGSPACE was meant to return the > number of leading bytes in the underlying data buffer and that it was > only broken when someone decided to half-implement ext bufs. This > brokeness happened to live on in present-day systems and unbreaking it > should not be put on hold for the sake of pseudo-compatibility, IMHO. > > > --- > > Keiichi SHIMA > > IIJ Research Laboratory <keiichi@iij.ad.jp> > > KAME Project <keiichi@kame.net> > > > > -- > Bosko Milekic > bmilekic@technokratis.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011026092840.F64631>