* Peter Wemm <pe...@wemm.org> [081216 20:12] wrote:
> On Sat, Dec 13, 2008 at 1:59 PM, Bjoern A. Zeeb <b...@freebsd.org> wrote:
> > De-virtualize the MD5 context for TCP initial seq number generation
> > and make it a function local variable like we do almost everywhere
> > inside the kernel.
> [..]
> > --- head/sys/netinet/vinet.h Sat Dec 13 21:17:46 2008 (r186056)
> > +++ head/sys/netinet/vinet.h Sat Dec 13 21:59:18 2008 (r186057)
> > @@ -142,7 +142,6 @@ struct vnet_inet {
> > int _isn_last_reseed;
> > u_int32_t _isn_offset;
> > u_int32_t _isn_offset_old;
> > - MD5_CTX _isn_ctx;
> >
> > struct inpcbhead _udb;
> > struct inpcbinfo _udbinfo;
>
> I'm bitterly unhappy with this. Every time these structs are touched,
> either directly or indirectly, there is a guaranteed ABI breakage with
> kernel modules.
>
> There needs to be a __FreeBSD_version bump (or something similar)
> every time any of these structures change, and any kernel modules
> *must* be prevented from loading. It can't be a >= some version, it
> has to be an exact match.
Peter, at Juniper we have what's called a "flag day" which sort of
means that nothing will work past a certain point if you mix pre
and post modules. Perhaps we just need a monotonically increasing
kernel_flag parameter that the kernel linker will check on module
load time.
> With the global variable method the linker calculates the offsets at
> load time. With this abomination, the knowledge of the structure
> layout is compiled into the generated code with no chance of a fixup.
> There are no sanity checks. If a module that referenced _isn_ctx is
> loaded the old way, there would be a link error. The new way will
> have it silently trash _udb instead.
There's no "structure size changed" hook? I could have sworn that
linker could warn about that... or are you saying that making this
a global explicitly deactivates this check?
> There is a whole world of hurt being unleashed here. I suspect that
> we might even be possible to run out of digits in our
> __FreeBSD_version numbering scheme.
maybe another variable, like above would be useful.
--
- Alfred Perlstein
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
