re: Support for multi-position electro-mechanical keylocks

[matthew green <mrg%eterna.com.au@localhost>]

   >> - Generic support for keylocks in the kernel.  The number of keylock
   >> positions and the current keylock position can be read from the  
   >> kernel
   >> using 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 -0000
   >
   > I do not agree that it should go there. Functionality is not a part of
   > the 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  

this is where you argue against your own proposal, and against
our current practises.

"generic drivers" belong in src/sys/dev.

please make this src/sys/dev/keylock.c.


.mrg.