Date: Fri, 7 Jan 2011 08:20:23 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-hackers@freebsd.org, lev@freebsd.org Cc: phk@freebsd.org Subject: Re: Building "third-party" modules for kernel with debug options? Message-ID: <201101070820.24144.jhb@freebsd.org> In-Reply-To: <1241746160.20110107151559@serebryakov.spb.ru> References: <1241746160.20110107151559@serebryakov.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, January 07, 2011 7:15:59 am Lev Serebryakov wrote:
> Hello, Freebsd-hackers.
>
>
> I've found, that "struct bio" is depend on state of "DIAGNOSTIC"
> flag ("options DIAGNOSTIC" in kernel config). But when I build
> third-party GEOM (or any other) module with using of <bsd.kmod.mk>,
> there is no access to these options. So, module, built from ports, can
> fail on user's kernel, even if it built with proper kernel sources in
> "/usr/src/sys". Is here any solution for this problem?
>
> P.S. NB: GEOM module is only example, question is about modules &
> kernel options in general, so I put this message on Hackers list.
In general we try to avoid having "public" kernel data structures change size
when various kernel options are in use. Some noticeable exceptions to this
rule are PAE (i386-only) and LOCK_PROFILING (considered to be something users
would not typically use). DIAGNOSTIC might arguably be considered the same as
LOCK_PROFILING, but I am surprised it affects bio. It should only affect a
GEOM module that uses bio_pblockno however in this case since you should be
using kernel routines to allocate bio structures rather than malloc'ing one
directly. Perhaps phk@ would ok moving bio_pblockno up above the optional
diagnostic fields.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201101070820.24144.jhb>