[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Pid lkm
> What you could do to schedule some kernel code to run, is
> make a user space
> prog which write's to a device or /proc entry, this can
> trigger the code to
In what context?
To access userspace data, you must be in a process context. Fx. you cannot
access userspace data from an interrupt.
Or do you think the process that opens the device, just place the data
somewhere trigger a bit to tell that the data is there. And then puts itself
on the queue and waits, for some other kernel process to take care of the
data, and to wake the process again?
In a module you can call sleep_on_timeout(), that puts you on the queue,
instead of making a busy wait. How would this be possible if there isn't any
process context in the execution?
Take a look at /proc/self, it is a symbolic link to the /proc entry of the
current process, if you look at the link from another shell (and thereby
another pid) you will see that the link has changed, to point at you new
pid. How come that?
Take look at linux/fs/proc/base.c and the function proc_self_readlink()
(line 915 in 2.4.18).
It uses the current->pid variable to make the symbolic link. How come this
work if the are no pid in kernel code?
Student at SDU Sønderborg. www.sdu.dk
Writing final project at Danfoss drives A/S. http://drives.danfoss.com
Tlf: 74 88 54 62