Building "third-party" modules for kernel with debug options?

Lev Serebryakov lev at FreeBSD.org
Fri Jan 7 17:46:44 UTC 2011


Hello, John.
You wrote 7 января 2011 г., 16:20:23:


>>   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.
  I've  got  "bio_caller2 used by the provider XXX" panic when kernel
  had DIAGNOSTIC and goem_raid5 had not...

  I've   redirected  this  answer  into  GEOM  list,  as  it  is  more
  GEOM-specific than my original message.

-- 
// Black Lion AKA Lev Serebryakov <lev at FreeBSD.org>



More information about the freebsd-geom mailing list