So I want to get some kernel routine called....

[Arlie Stephens]

Hi Folks,

It's that BSD engineer again, trying to do something in linux and
unable to see the _linux_ way to do it ;-) 

I have some kernel routine I'd like to get called, with the decision
to call it made in user space. Obviously I could do this by making it
into a full blown system call, but that's pretty much never the right
answer, except for a quick hack. 

In FreeBSD, I'd make it into a sysctl, and have my user space script
do something like "sysctl debug.call_my_hack=1" I'd then define
call_my_hack to to be the type of sysctl that calls a procedure, using
a convenient macro, and I'd be done. 

In linux I've determined that the /proc/sys interface is the preferred
way to access sysctl's, but that even that is possibly deprecated in
favour of sysfs. Documentation on implementing sysctl's is conspicuous
by its absence, and much of what I've found applies only to the
deprecated interface. In particular, the "strategy" routine appears
designed for my purpose - but is never called if you come in to the
kernel with read/write to /proc/sys/whatever. Probably I can get the
effect I want by (ab)using the proc_handler function pointer - but is
that what I "should be doing"? 

As for sysfs, it's tightly tied to the physical device hierarchy. I
can't even find how one is supposed to deal with pseudo-devices. There
do however seem to be a few interesting things in /sys/kernel which
clearly have nothing to do with the device hierarchy. Probably
checking their implementation will teach me how to use this ... but
not whether it's the "right thing to do". 

For what it's worth, there is a pseudo-device driver involved, but no
convenient /dev interface to issue ioctls on. (Probably calling it a
pseudo-device exagerates its abilities.) 

As always, I'm looking primarily at 2.6.32, but want to write code
that's good for the long haul, and potentially upstreamable. 

So, how would someone who thinks in linux go about doing this?

Thanks for any enlightenment.

--
Arlie

(Arlie Stephens					arlie at worldash.org)