tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

re: compat kernel modules and GENERIC



   Should 'options COMPAT_xx' really be commented out in the GENERIC kernel
   configuration?
   
   In -current, code for compatibility with NetBSD 5.0 is divided
   between #ifdef-COMPAT_50 code and a compatibility kernel module
   (sys/compat/common/*_50.c).
   
   It looks to me like 3.0 compatibility is likewise divided between both
   some #ifdef-COMPAT_30 code (see sys/dev/vnd.c) and a module.
   
   As a consequence, one needs both 'options COMPAT_xx' and a compatibility
   kernel module to support old kernel ABIs.
   
   Developers foresee that we will move all of the compatibility that
   remains #ifdef'd into the kernel modules.  In the mean time, it seems to
   me that 'options COMPAT_xx' should not be commented out in the GENERIC
   kernel configuration for i386.  Or is there something that I am missing?


the problem is that if you define COMPAT_XX in the kernel itself
you break the "compat" module.  it won't work.

so defining that in the (i386) GENERIC is currently the wrong
thing to do.  COMPAT_50 and "compat module" are not currently
working and need some help, but simply putting COMPAT_XX into
i386 GENERIC won't fix anything by itself (so i understand.)


your vnd / COMPAT_30 example mostly shows that there are more
#idef COMPAT's to be removed from the kernel, and afaik, isn't
that relevant (ie, it's just a bug in COMPAT_30 today.)


i'm not sure what a simple "for now" workaround would be,
except to not use GENERIC but MONOLITHIC.  the right long term
fix is to make "compat" module work for COMPAT_50 things in
a current "GENERIC" configuration.  the majority of the work
to do that is to simple *take out* "#ifdef COMPAT_50"
conditionals from standard kernel code.  that leaves the
systems in place that "compat" module needs.


.mrg.


Home | Main Index | Thread Index | Old Index