On Mon, Oct 31, 2011 at 9:42 AM, Randy Dunlap <rdunlap@xxxxxxxxxxxx> wrote: > > Actually adds "select NET", a reverse dependency. :( > > Linus was quite vocal about not allowing MD to select BLOCK. > See https://lkml.org/lkml/2011/8/10/527 > and https://lkml.org/lkml/2011/8/10/533 > > To me this is very similar. I do agree. "select" makes sense when it's a way for a user to not have to care about some small helper thing that is really not obvious for a casual user. But darn it, if somebody has said "no networking", then some random small feature shouldn't suddenly select it. IOW, it's about "relative importance". We should use "select" when some feature that should be user-visible selects some details. And we should use "depends on" when there's a major subsystem that some small detail depends on. So classic and obvious uses where "select" is appropriate is when a driver needs some helper library to work (eg "select FW_LOADER" or "select CRC32"). And a classic and obvious case where "depends on" is the appropriate choice is when it depends on a major subsystem ("depends on PCI" or "depends on USB" or "depends on X86"). And I think "NET" definitely falls into that second category - exactly the same way "BLOCK" fell into it. You don't "select" major subsystems - if somebody turned off the subsystem, we turn off the stuff that depends on it. (Of course, in reality, pretty much nobody turns off NET, I suspect. But if some embedded place really doesn't want it, then damn it, we shouldn't ask about the odd crypto user interfaces, because they really aren't major enough, and the embedded platform is clearly trying very hard to run small). Linus -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
