[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: i386 and the COMPAT_50 option
On Fri, Jan 23, 2009 at 06:15:32PM +0000, Christos Zoulas wrote:
> In article <200901231755.n0NHtla3004644%lothlorien.nfbcal.org@localhost>,
> Brian Buhrow <buhrow%lothlorien.nfbcal.org@localhost> wrote:
> > Hello. Sorry if this is a dumb question, but doesn't this change sort
> >of imply that if I want to change my compatibility options, I now have to
> >modify more than just a config file? I now have to modify Makefiles all
> >over the system as well as the config file? that seems like a step
> >backward, or I'm missing something completely obvious.
> It is even worse than that... Here's an explanation:
> Most compat code has been pushed into a module. Kernels without
> compat options, will load the compat module when a system call is
> needed. Unfortunately this does not cover all the bases; there are
> other compat hooks to functions for example in the routing socket
> code (net/rtsock.c) some ioctls, setsockopt, event reading code in
> wscons just to name a few. All this kernel compat code is conditionally
> compiled with #ifdef COMPAT_XX. So if you go in the pure module
> route, you'll lose the compatibility provided by those hooks so
> more things might not work. Currently the only way to provide full
> compat functionality is to define COMPAT_XX in your kernel. This
> is not ideal, because we would really like to push all that code
> into modules. Alas it is not as easy. Some solutions are:
> 1. Don't provide compatibility.
> + Simplifies code
> - Some programs don't work...
> 2. Always compile the hooks in the kernel, not conditionally.
> + Bloat
> - Difficult to separate compat and non-compat code.
> 3. Add indirection variables instead of hooks in the kernel
> and auto-load the compat module if the hooks detect that
> it is not.
> + clean
> - complicated
> 4. ?
Here are some more options to consider:
3. Structure the compat code as a full blown emulation like compat_linux.
Select it depending on binary type / ELF note. All compat code lives in
4. Give up and don't support native compat as a module. It was only 20kB
last time I looked and is not a security hole (excluding SA), so perhaps
it is just not worth the hassle. The emulations are easy to make into /
sustain as modules so this argument does not apply to them.
5. As #4 but don't even bother with release level granularity as the only
rational excuse for this is to make the kernel build with newer
6. Make native compatibility non-optional. Weeping and gnashing of teeth
Main Index |
Thread Index |