On Thu, 6 Sep 2001, Jari Ruusu wrote: [...] > There are places where crypto can't go, but Linux must go. I don't like it, > but I can understand keeping crypto out of mainline kernel. But logically, the only thing that is required is that the crypto and non-crypto branches are kept separate. It would fit this requirement just as well to have crypto in the mainline kernel, and a separate non-crypto kernel maintained, presumably with rather less effort than is currently required to maintain the crypto code separately. So why is the situation as it is? I don't know how kernel development works, perhaps somebody here who is more knowledgeable than me would like to comment. Of course, if things were to be organised in this way, somebody would have to maintain the non-crypto kernel, and I guess it might be harder to find people to do that than it currently is to find people (ie people on this group!) to maintain the separate crypto patch(es? -- I'm not up-to-date on how it works atm). I suppose there are two groups of candidate maintainers: people who want to get crypto into the mainline kernel who might promise to maintain a non-crypto patch (or un-patch, more like), and people who live in countries with restrictive crypto laws. Another argument that might be put forward is that the countries with restrictive laws on this aren't just dictatorships and communist countries but also major users of linux in the west like (still?) France. I think this argument is specious given the relative ease of removing crypto support compared to adding it. I guess my main point is that it is much easier to break something than to make it work, so maintaining a non-crypto branch would be far easier than maintaining a crypto patch. John Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
