I have a library of routines statically linked to the Linux kernel. I
(and others) then write modules that exercise, benchmark, verify, or
otherwise use those and other kernel routines.
I decided against having the modules dynamically add syscalls at
insmod time, and remove them at rmmod time, since it seemed messy to,
at rmmod time, kick off user processes that had acquired the syscall
number directly OR INDIRECTLY from the kernel. I thought about
writing a dynamic syscall interface that would have you open and close
dynamic syscalls, permitting invalidations of "open syscalls" to be
detectable. I decided against this, at least in the short term.
I thought about hacking procfs to permit reading and writing to my
module. Too slow, and clunky.
Using ioctl, seems to be just right, and I have done this.
So now, at insmod time, my module adds itself a chrdev entry WHEREEVER
ONE IS AVAILABLE, and removes it at rmmod time.
Well gee, now I have my very own major device number, how does the
user process open it? I have to first tell them what the major device
number is, and they (apparently) have to mknod a bunch of char-special
files to open and ioctl to. Okay, kinda clunky, but it works.
How do I tell him that the major device number is? Why, I use a
procfs file to give it to him. This last bit (getting the major
device number to the user process), seems to be consistantly left out
of discussion here. Am I unaware of something?
======================
My proposed solution:
======================
I would like my module to present a char-special file in /proc when
it's active, and remove it when de-activated. User processes only
need to know what name to look for, and ioctl/read/write to it at
will.
The only trick would be invalidating any open files when the module
gets rmmod'd so that if another module grabs the same major device
number, it doesn't get used instead (at least not without an exception
(signal) that forces the user to explicitly state "I meant to do
that!".
-- Perry