Re: [PATCH] Start of compat32.h (again)

Linus Torvalds (torvalds@transmeta.com)
Sun, 1 Dec 2002 10:54:38 -0800 (PST)


On Wed, 27 Nov 2002, David S. Miller wrote:
>
> I envisioned moving the compat stuff right next to the "normal"
> implementation.

Why?

> A problem currently, is that when people change VFS stuff up one has
> to pay attention to update all the compat syscall layers as well.

Doesn't matter. The thing is, you have two kinds of fixups for things like
VFS changes:

- compiler warning/error based fixups (in which case it doesn't _matter_
where it is, since in neither case will it get compiled for x86

- a simple "grep xxxx *.c" kind of approach.

Yes, the latter often misses out on architecture files, because people
just won't even look at hits in sparc/ppc64/xxx, either being too timid to
want to check, or just not caring. But if the file is in kernel/xxxx, it
will be noticed - at least as well as it would be if it was uglifying
regular files with #ifdef's.

> Now if we put the stuff next to the non-compat stuff, it likely won't
> get missed.

.. but it will have ugly #ifdef's inside the source file, something that I
absolutely detest.

Face it, the "compat" stuff is _secondary_. If it breaks, it breaks. It's
better to have the main code paths clean and unsullied, and take the risk
of occasionally breaking the compatibility stuff (that will break
occasionally anyway, see above).

Quite frankly, I want people to literally have the option to just ignore
the compat stuff, simply because it's not as important as the core kernel
code.

I see the compat32 patches as a convenience, and as a way to avoid
duplicating bus over the system. I do NOT consider it to be core
functionality, and I do _not_ think it should be a first-class citizen.
Sorry, guys. Code cleanliness is _way_ more important to me.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/