From owner-freebsd-current Wed Nov 27 13: 5: 3 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C1E437B401; Wed, 27 Nov 2002 13:05:01 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 590B143EAF; Wed, 27 Nov 2002 13:05:00 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id QAA17082; Wed, 27 Nov 2002 16:04:57 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id gARL4PR78777; Wed, 27 Nov 2002 16:04:25 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15845.13145.445000.166358@grasshopper.cs.duke.edu> Date: Wed, 27 Nov 2002 16:04:25 -0500 (EST) To: Terry Lambert Cc: Andrew Gallatin , Robert Watson , Luigi Rizzo , current@freebsd.org Subject: Re: mbuf header bloat ? In-Reply-To: <3DE52F25.61FAB63C@mindspring.com> References: <15840.8629.324788.887872@grasshopper.cs.duke.edu> <15844.60298.44810.750373@grasshopper.cs.duke.edu> <3DE5275E.9D3E9F9B@mindspring.com> <15845.10492.726439.227885@grasshopper.cs.duke.edu> <3DE52F25.61FAB63C@mindspring.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert writes: > Andrew Gallatin wrote: > > Terry Lambert writes: > > > Andrew Gallatin wrote: > > > > What I (as a 3rd party driver author working in a GNUish > > "This is how I do it." > > > <...> > > > > > > How is one supposed to build a 3rd party module these days? > > "How are you supposed to do it?" > > > > One is not. The vendor supplies only a binary. > > > > Damn it Terry, I AM the vendor. Somtimes I wonder if you even read > > the articles you reply to. I'm asking how the vendor (me) is > > supposed to build a binary module and I gave an example of how currently > > do it. > > You're the vendor in the first statement, and a consumer in the > second. I"m the vendor in both statements, no matter how you choose to misread my words. > The topic of the post to which you were replying was third party > binary compatability. > > The answer is that if the structures change, then there is no > binary compatability without source code, period. Yes there is. You can be binary compatable ONLY with a kernel with options MAC. > It seemed to me that you were assuming access to the source code > for consumers of third party modules. > > I think the issue that Robert is concerned about is MAC modules > that are provided by a third party to a consumer of FreeBSD and > the modules, and for which the structure changes and so on can > not be permitted. > > This mnakes sense, because the MAC code is being developed under > a DARPA contract, and it's likely that the module source code and > the modules won't be available to the end users, let alone the > general public, without some kind of security clearance, and then > probably not then. If you're a vendor of a device which inserts MAC mtags and needs options MAC, you put this code in your driver: if (mbstat.m_mhlen != MHLEN) { printf("Please rebuild your kernel with 'options MAC'\n"); goto atach_failed_no_mac; } I've already got code like this in my driver to check that m_mclbytes and m_mlen is what I expect it to be, since people sometimes change them. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message