[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Pid lkm
Sorry I messed up with the lists. this is a reply to a letter in
I apologize for the confusion I have made here.
BTW. it would be so much easier if the list servers inserted a reply-to
header in the postings.
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
> -----Original Message-----
> From: Hansen Martin
> Sent: Monday, May 27, 2002 5:50 PM
> To: Dev-Etrax (E-mail)
> Subject: 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
> > run.....
> 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
> (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?
> Martin Hansen
> 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