- Generic support for keylocks in the kernel. The number of keylockpositions and the current keylock position can be read from the kernelusing two functions, userland can access them through the hw.keylock.npos and hw.keylock.pos sysctl variables.Index: sys/kern/kern_keylock.c =================================================================== RCS file: sys/kern/kern_keylock.c diff -N sys/kern/kern_keylock.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ sys/kern/kern_keylock.c 2 Aug 2009 09:25:19 -0000I do not agree that it should go there. Functionality is not a part ofthe kernel core, nor really generic across the platforms. It might evolve to something, but currently it is just a callback abstracted in sys/ kern.Please keep that in the driver side.
(Sorry for the delayed response)I think that sys/kern is actually the right place for various reasons: A service is provided to other parts of the kernel, like e.g. to the kauth(9) framework. The actual keylocks can be implemented very differently, using GPIO is only one possible example (after all, the keylock support would not make sense if there wasn't at least one sample implementation), so the keylock proper needs a driver, and I think it's a good idea if the keylock driver then registers itself at a central instance. The plan is, btw, to support multiple locks in the future, so there must be "something" that decides the overall "closedness" of the system. And that "something" is the keylock part in sys/kern in this implementation. This way, when the optional keylock support is compiled in, it can be used right away. If the "central something" was (pseudo)device, a user of it would have to wait until the driver attached etc. and I think the whole mechanisms would get more complicated.
The keylock support is actually generic accross all platforms, it is not hardware or architecture dependent. The atcual keylock driver can of course be very hardware dependent.
- Marc Balmer