Hi,
I have a kernel FIFO for special keyboard events (considered asynchronous
to normal keypresses) and a userspace script (invoked by keyboard_signal
from init) which reads them (one at a time).
And no, these keys can't be handled like normal extended keys as they use
_a very_ different route to reach the kernel -- and neither would I want
to - they're of the: lock keyboard, turn off screen, disk, sleep,
hibernate, etc variety.
Currently, I'm using a mangled proc interface (which is very much a
hack: reading /proc/special_keycode returns the current value at the head
of the FIFO, and if the seek offset was 0 then it pops the FIFO. This
last part is due to 'cat /proc/file' doing two reads, the first for the
data with a 1K buffer and the second to determine we're at EOF, both call
the proc read interface. nb. this means that if proc exports a value that
is variable length (like jiffies), it is possible for cat /proc/file to
return junk (at the end of the file) if the proc file length increases
between first and second read invocation (unlikely, but possible...) -
perhaps this should be fixed more globally - but how? by cacheing?
remembering a given proc fd has already EOF'ed and not invoking the
proc read procedure a second time?).
What would be considered 'the right way' to return an integer
from a 30-value integer FIFO in the kernel to a userspace script (and
pop the FIFO at the same time).
This is called very very rarely (once a couple minutes, sometimes
even hours) as it only happens when the user actually presses some
unusual key-combination. However a FIFO is necessary because a single
keypress combination usually results in 2-3 events.
Thanks,
MaZe.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Maciej,
On Friday 07 November 2003 12:59, Maciej Zenczykowski wrote:
> I have a kernel FIFO for special keyboard events (considered asynchronous
> to normal keypresses) and a userspace script (invoked by keyboard_signal
> from init) which reads them (one at a time).
Just write a simple misc device, where you implement read and write.
open -> control open behavior, setup file->private to point to your data
read -> reads from your FIFO one value at a time
write -> flush fifo (not needed?)
llseek -> no_llseek (since you are a fifo!)
poll -> waits for at least one entry in the fifo
release -> free your private data allocated for file->private
In read() you check whether *ppos != file->f_pos and return -ESPIPE in this
case.
You also check, whether size is the right size for your data and return
- -EINVAL, if not.
Implementing poll would be nice, if you want your script to deamonize,
but is not needed, if you trigger reading via init.
write ignores all arguments and simply flushes the FIFO.
If you allow multiple open by not returning -EBUSY on the second open,
you should take care of locking your FIFO.
> And no, these keys can't be handled like normal extended keys as they use
> _a very_ different route to reach the kernel -- and neither would I want
> to - they're of the: lock keyboard, turn off screen, disk, sleep,
> hibernate, etc variety.
>
> Currently, I'm using a mangled proc interface (which is very much a
> hack: reading /proc/special_keycode returns the current value at the head
> of the FIFO, and if the seek offset was 0 then it pops the FIFO.
/proc is only good for showing values, but not for FIFOs.
> What would be considered 'the right way' to return an integer
> from a 30-value integer FIFO in the kernel to a userspace script (and
> pop the FIFO at the same time).
A misc character device is perfect.
BTW: Which kernel(s) do you target in your development?
Regards
Ingo Oeser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/rOYsU56oYWuOrkARAtxgAKCbbifYj95CtzjOgk6bDJ0q0ZWjbQCeNoGz
aHFSYTPCQRb/ntKVMWVkyvM=
=GmJl
-----END PGP SIGNATURE-----
I'm not sure if this is compatible with the zen of /proc, but one technique for
handling such "destructive reads" from a FIFO, is to only pop the FIFO with an
explicit operation, such as a write.
Perhaps this can work for you?
Thanks, Shaheed