Sharing data between user space and kernel
anand at pythagoras.math.uwaterloo.ca
Sun Dec 7 11:41:22 PST 2003
A look at the copyin() code in the kernel reveals that all the kernel
needs to do to access the data(address space) of a user process is
1. Get the current thread, which I saw is done using the PCPU_GET macro.
So I suppose this is always preserved upon a system call.
2. Set the segment register for the user process correctly.
And magically, all the user process's data can now be accessed by the
Is that correct? In the event of which, it would become really easy for
a user process to allocate a chunk of memory and all a kernel module needs
to do to "implement shared memory" is do the steps 1 & 2 and access the
Of course there is the question that the user process is "swapped" out
after the system call and some other thread starts running in between in
which case curthread should point to some other thread and not the one
that issued the system call. But then, isn't this what happens upon
every system call normally, when the kernel does the steps 1 & 2 to
obtain the data arguments which are passed to the system call. So this
is hardly a problem. So, can shared memory be implemented this way
instead of the more traditional "pseudo-device" way?
Appreciate any comments on this(please do a CC to my email address, in
case you choose to respond).
More information about the freebsd-hackers