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/
This archive was generated by hypermail 2b29 : Sat Dec 07 2002 - 22:00:11 EST