David> For example, the fact that I have to go groveling in
David> arch/foo/lib/whoknowswhatfile.whoknowswhatextension to look
David> at the memcpy/checksum/whatever implementation is
David> completely busted.
I see your point. Still, I think there is a lot to be said for
keeping arch code in arch/xxx and include/asm-xxx. It means that
someone working on a new port (I don't necessarily mean a totally new
arch, but also adding support for some new CPU model or platform) has
a well-defined set of directories to look at.
It's also nice that the xxx-arch maintainers can say "we are the rulers
of arch/xxx and include/asm-xxx" and know that any changes outside of
those directories have to go through lkml.
By the way, I agree that it would be good if <asm/string.h> had
something like
/* See arch-xxx/lib/string.S for implementation of these */
Still, I don't think I would like it if we had
alpha/ arm/ arm26/ cris/ h8300/ i386/ ia64/ m68k/ m68knommu/
mips/ mips64/ parisc ppc/ ppc64/ s390/ sh/ sparc/ sparc64/ um/
v850/ x86_64/ generic/
directories scattered all over the source tree.
- Roland
-
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/