Date: Sun, 7 Dec 2003 14:41:17 -0500 From: Anand Subramanian <anand@pythagoras.math.uwaterloo.ca> To: freebsd-hackers@freebsd.org Cc: anand@cs.uwaterloo.ca Subject: Sharing data between user space and kernel Message-ID: <20031207144117.A6912@pythagoras.math>
next in thread | raw e-mail | index | archive | help
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 kernel directly. 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 data. 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). Anand
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031207144117.A6912>