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