Messages in this thread | | | Date | Mon, 07 Jul 2003 20:35:16 -0700 (PDT) | Subject | Re: crypto API and IBM z990 hardware support | From | "David S. Miller" <> |
| |
From: Roland Dreier <roland@topspin.com> Date: 07 Jul 2003 20:37:09 -0700
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.
I again disagree. We're talking about things here where the default you get is _working_.
Only if you want to enhance or _optimize_ your port do you need to modify any of this crap.
In this way it's fundamentally different from things that one normally finds under arch/foo and include/asm-foo
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.
This isn't nice, it's rather bad for this case.
I think it'd be great that the "crypto maintainer" can be the one by which "crypto changes" need to go through. So again, I totally disagree with your assesment.
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.
I see no problem with this at all. In fact, I wish we had a much higher directory to file ratio in the kernel tree.
And hey, if I went "find crypto -type d -name sparc" I'd know if there are sparc optimizations for the crypto library. How might you do this with the current "everything and it's mother under arch/" scheme? Answer: you can't. - 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/
| |