On Fri, 30 Dec 2005, Matt Mackall wrote:
> >
> > Where's the problem with the __HAVE_ARCH_* mechanism?
>
> The head penguin peed on it last week.
Actually "sprkinling with penguin pee" means that something is blessed
(it's like a kernel baptism). Maybe that's not very civilized, but hey,
penguins don't have thumbs, and are thus kind of limited in their actions.
Don't be speciest.
So the head penguin didn't pee on it, it turned its back in disgust, and
hoped that it would freeze to death in the arctic winter.
And no, I don't like the __HAVE_ARCH_xxx mechanisms at all. They are
pointless, and hard to follow. If an architecture wants to use a generic
mechanism, it should do one of the following (or a combination):
- use the config file mechanism, and use
obj-$(CONFIG_GENERIC_FOO) += generic-foo.c
in a Makefile to link in the generic version.
Examples: CONFIG_RWSEM_GENERIC_SPINLOCK.
- just include the generic header from its own header, eg just do a
#include <asm-generic/div64.h>
or similar.
Now, the latter in particular is very easy to follow: if you look into the
<asm/div64.h> file and see that it just includes <asm-generic/div64.h>,
it's very obvious what is going on and where to find the real
implementation. You never have to wonder what the indirection means.
Similarly, anybody that fixes the generic header file can _trivially_ grep
for its use. So the code stays clean, and there are absolutely zero
compile-time conditionals, and the linkages both ways are obvious. And
architectures that do _not_ use the generic routines are totally
unaffected by them, and they don't need to specify any flags like "I have
my own routines" to disable things.
Now, the CONFIG_GENERIC_FOO thing is a bit less obvious, and you may have
to know about that config option in order to realize that a particular
architecture is using a generic library routine, but at least with those
Kconfig options, the language to describe them is clean these days, and
it's _the_ standard way to express configuration information. So it may be
a bit subtler and more indirect, but once you get used to it, it too is
very clean.
In contrast, the __HAVE_ARCH_xxx thing has zero upsides. It just causes
#ifdef mess in C source files, and unnecessary noise in standard header
files. I know it's been there for a long time, but just grep for
__HAVE_ARCH_MEMCPY and cry. Why the hell should all the architectures that
have their own optimized memcpy() have to tell the rest of the world about
it?
[ Yeah, I know why: bad implementation choice. It could easily have been
done with the asm-generic approach or CONFIG_GENERIC_MEMCPY, but it
wasn't. Note that the __HAVE_ARCH_xxx thing isn't even a standard form:
sometimes it's the negation: __ARCH_WANT_xxx, and sometimes it's called
something else entirely, like USE_ELF_CORE_DUMP or HAVE_PCI_MMAP, or
ARCH_HAS_PREFETCH or HAVE_CSUM_COPY_USER. My point being that it's
totally ad-hoc and random. ]
So we do have tons of ugly stuff, I just am trying to argue for not making
more of it (I don't think it's a big enough deal that it would be worth it
trying to clean up old uses).
If you look at the mutex patches, for example, I think everybody will
agree that they look much _better_ after they moved to just using the
trivial "#include <asm-generic/mutex-xyzzy.h>" format. At least I don't
_think_ this is just a personal weird hang-up of mine. It's literally a
cleanliness issue.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
