On Tue, Nov 30, 2021 at 07:24:15AM -0500, Jeffrey Walton wrote: > On Mon, Nov 29, 2021 at 6:07 PM Greg Kroah-Hartman > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > ... > > Sometimes, yes, it is valid to have different implementations for things > > that do different things in the same area (like filesystems), but for a > > core function of the kernel, so far the existing random maintainer has > > not wanted to have multiple implementations. Same goes for other parts > > of the kernel, it's not specific only to this one very tiny driver. > > > > As a counterpoint, we do not allow duplicate drivers that control the > > same hardware types in the tree. We have tried that in the past and it > > was a nightmare to support and maintain and just caused massive user > > confusion as well. One can argue that the random driver is in this same > > category. > > I think an argument could be made that they are different drivers > since they have different requirements and security goals. I don't > think it matters where the requirements came from, whether it was ad > hoc from the developer, NIST, KISA, CRYPTREC, NESSIE, or another > organization. > > Maybe the problem is with the name of the driver? Perhaps the current > driver should be named random-linux, Stephan's driver should be named > random-nist, and the driver should be wired up based on a user's > selection. That should sidestep the problems associated with the > "duplicate drivers" policy. The "problem" here is that the drivers/char/random.c file has three users, the userspace /dev/random and syscall api, the in-kernel "here's some entropy for the random core to use" api, and the in-kernel "give me some random data" api. Odds are, you REALLY do not want the in-kernel calls to be pulling from the "random-government-crippled-specification" implementation, right? Again, just try evolving the existing code to meet the needs that you all have, stop trying to do wholesale reimplementations. Those never succeed, and it's pretty obvious that no one wants a "plugin a random random driver" interface, right? thanks, greg k-h
