Date: Wed, 27 Nov 2002 16:04:25 -0500 (EST) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Terry Lambert <tlambert2@mindspring.com> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, Robert Watson <rwatson@freebsd.org>, Luigi Rizzo <rizzo@icir.org>, current@freebsd.org Subject: Re: mbuf header bloat ? Message-ID: <15845.13145.445000.166358@grasshopper.cs.duke.edu> In-Reply-To: <3DE52F25.61FAB63C@mindspring.com> References: <15840.8629.324788.887872@grasshopper.cs.duke.edu> <Pine.NEB.3.96L.1021127095837.43889C-100000@fledge.watson.org> <15844.60298.44810.750373@grasshopper.cs.duke.edu> <3DE5275E.9D3E9F9B@mindspring.com> <15845.10492.726439.227885@grasshopper.cs.duke.edu> <3DE52F25.61FAB63C@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15845.13145.445000.166358>