Messages in this thread | | | Subject | Re: crypto API and IBM z990 hardware support | From | Roland Dreier <> | Date | 07 Jul 2003 20:37:09 -0700 |
| |
Christoph> crypto/arch/ sounds like a bad idea. We really should Christoph> avoid arch code outside arch/ and include/asm*. So Christoph> arch/<foo>/crypto/ as suggested by Thomas is much Christoph> better.
David> I totally disagree. I think the way we do things today is David> _STUPID_. We put arch code far away from the generic David> version which makes finding stuff very difficult for people David> inspecting the code for the first time.
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/
| |