Re: Accessing Physical Memory & Other Process's Address Space

Tim Roberts <spamtrap@xxxxxxxxxx> wrote in
news:hg8lq314n5p0oc2qn1vcrubv1avf6e7les@xxxxxxx:

"mybwpp@xxxxxxxxxxxxxx" <spamtrap@xxxxxxxxxx> wrote:

In 32 bit protected mode, each user process is allocated a 4GB address
space, whereby program data and code resides in lower 2GB and kernel
is mapped in the upper 2GB (in some cases it is 3GB for user and 1GB
for kernel). However the part of linear address space where kernel is
mapped, is not accessible to user process, due to the difference in
privilege levels. The question is that, do kernel mode processes also
get their address space mapped in the same manner.

In Windows and Linux, at least, there is no such thing as a "kernel
mode process". Processes simply exist. Sometimes they run in user
mode, sometimes they run in kernel mode. In user mode, part of the
address space is visible. In kernel mode, all of it is.

Somewhat tangential to the original thread, but just to clarify:
In Linux, at least, there is the notion of a "kernel-mode thread" which
is for all intents and purposes equivalent to a kernel-mode process.
These threads are basically just like other threads except that they
don't have the user-mode portions attached (i.e. the user-mode address
space consisting of code and data segments). So when the scheduler task-
switches to a kernel-mode thread, it need only switch the kernel-mode
stack -- the page tables don't need to be switched.

Other than that, these threads are analogous to ordinary threads *while*
they're running in kernel-mode. They simply have a top-level loop
somewhere -- usually an infinite loop -- that waits for something to do
(or just waits for x number of clock ticks), does something, then
repeats. Conceptually, it's as if there were a special-purpose system
call that was invoked once, then simply never completed (and hence never
returned to user-mode).

I believe Windows has an equivalent mechanism though I haven't done any
Windows kernel programming in a very long time.


GH

.

Relevant Pages

  • Re: Communications kernel -> userland
    ... > form the kernel to the user process; ... > to the user process memory. ... > handle packets, perhaps ...
    (freebsd-hackers)
  • Re: Communications kernel -> userland
    ... Write directly to a file from the kernel. ... a file provided by an authorized user process. ... Expose it using a special socket type. ... a special-purpose system call or sysctl if you don't mind a lot of context ...
    (freebsd-hackers)
  • Re: Sharing data between user space and kernel
    ... you can't just dereference a 32-bit pointer when the kernel is ... Set the segment register for the user process correctly. ... can shared memory be implemented this way ... a look at the sysctlcode, you'll see that it wires userspace pages into ...
    (freebsd-hackers)
  • Re: SCHED_FIFO and SCHED_RR broken by cfs
    ... SCHED_FIFO realtime scheduler. ... In my opinion a high priority real time user process with SCHED_FIFO ... should be only interrupted by the kernel or a process with an higher ...
    (Linux-Kernel)
  • Re: File access
    ... If you consider a kernel module which, in some event, ... chunk of data it needs to stall until the user process has finished. ... >> to pass the configuration to the driver. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)