On 5/30/06, Antonino A. Daplas <[email protected]> wrote:
I was thinking of reviving this patch, because of problems with suspend/
resume and mode setting. But if there is a plan to put an emulator as part
of the kernel library, I'll hold off.
There's a plan but nobody is working on it right now. The first step
is to get klibc in and that seems to be taking forever. klibc is
making progress, there is a merged kernel/klibc git tree available,
I'm just not sure when it will get merged for real.
I'm also thinking of using a different user-kernel interface. The old
patch creates a misc device which the daemon opens, but can the kernel
connector do the job? I don't know anything about this.
My app wrote its results and signaled it was finished by writing to a
sysfs attribute. I'm sure one of the experts on the list will tell us
the right way to do this.
The flow is like this:
normal user ioctls device
kernel driver calls usermodehelper
what's the right way for the kernel driver to sleep here?
user space run the helper app as root
app writes to sysfs attribute
kernel driver wakes
returns out to normal user
If you look at the code for /sys/class/firmware it does most of what is needed.
Check out drivers/base/firmware_class.c
This code can be generalized to support calling out to arbitrary user
mode helpers instead of the specific firmware helper. I think I posted
a patch to do this, I don't have it locally but it may be in the
archives.
PS: This user helper need not just do x86 calls, it might use OF or even
X. (I believe the Xen people have something similar). A userspace
framebuffer driver usable by the kernel console is definitely possible.
I have never been against having the driver call out into user mode,
in fact it is required for some hardware. The model I would like to
see is for everything to be controlled via a device node. Having the
device node lets you control it as a normal user and then use the
device driver to gain root when you have to have it.
--
Jon Smirl
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
