On Wednesday 27 June 2007 04:48:56 Henrique de Moraes Holschuh wrote: > (a) is just broken, unless one is to take it as "never use it". And I am > really not sure about (b). It *is* better than just using whatever crap we > found first (or last), but it is the wrong solution for a problem that we > really should not have in the first place if someone had thought a bit > before adding a misc device for something that has no reason to be unique in > a system.
Well, we have that userspace ABI of one hwrng char device. I did not invent that. It's kind of broken, yes. And changing it in a compatible way is probably difficult. > Instead of papering over the problem with borked solutions, maybe we should > just export ALL HRNGs to userspace. While at it, please add whatever is And then we would _still_ export some kind of hint for rngd that the CPU rng device should be preferred over the bcm43xx device. rngd needs some basic hint about the devices. How would you implement that? (We're back to my TYPE_XXX definitions ;) ) > needed so that userspace can talk to the kernel driver to get vital > information about the HRNG device the driver might have (the current > interface is a bad simplistic hack). What is "vital information"? My TYPE_XXX categories? ;) > Let userspace get the data from whichever HRNG it wants, process it in any It _can_. We can switch the RNG in sysfs. So userspace _can_ get data from whichever HWRNG it wants. > way it wants and pipe it back through /dev/random IOCTLs. And let it do it > for as many HRNGs it wants at the same time. That's an improvement, yes. > And if you must have /dev/hw_random point somewhere, let udev scripts or > something else like that take care of it. Could do that, yes. -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
