Re: crypto API and IBM z990 hardware support

[Roland Dreier <roland@topspin.com>]

    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