Re: What is the truth about Linux 2.4's RAM limitations?

[Jesse Pollard]

On Tue, 10 Jul 2001, Richard B. Johnson wrote:
>On Tue, 10 Jul 2001, Jonathan Lundell wrote:
>
>> At 1:35 PM -0400 2001-07-10, Richard B. Johnson wrote:
>> >Unlike some OS (like VMS), a context-switch does not occur
>> >when the kernel provides services for the calling task.
>> >Therefore, it was most reasonable to have the kernel exist within
>> >each tasks address space. With modern processors, it doesn't make
>> >very much difference, you could have user space start at virtual
>> >address 0 and extend to virtual address 0xffffffff. However, this would
>> >not be Unix. It would also force the kernel to use additional
>> >CPU cycles when addressing a tasks virtual address space,
>> >i.e., when data are copied to/from user to kernel space.
>> 
>> Certainly the shared space is convenient, but in what sense would a 
>> separate kernel space "not be Unix"? I'm quite sure that back in the 
>
>I explained why it would not be Unix.
>
>
>> AT&T days that there were Unix ports with separate kernel (vs user) 
>> address spaces, as well as processors with special instructions for 
>
>No. The difference between kernel and user address space is protection.
>Let's say that you decided to revamp all the user space to go from
>0 to 2^32-1. You call the kernel with a pointer to a buffer into
>which you need to write kernel data:
>
>You will need to set a selector that will access both user and
>kernel data at the same time. Since the user address space is
>paged, this will not be possible, you get one or the other, but
>not both. Therefore, you need to use two selectors. In the case
>of ix86 stuff, you could set DS = KERNEL_DS and ES = a separately
>calculated selector that represents the base address of the caller's
>virtual address space. Note that you can't just use the caller's
>DS or ES because they can be changed by the caller.

Sure you can - But you do have to modify the page tables for the
kernel access. You also have to verity that the page is valid
to the user, that the offset to the location to modify is
valid from both the users context and the kernel context.

>Then you can move data from DS:OFFSET to ES:OFFSET, but not the
>other way. If you need to move data the other way, you need DS: = a
>separately calculated selector that represents the base address of the
>caller's virtual address space, and ES = KERNEL_DS. Then you can copy from
>ES:OFFSET to ES:OFFSET (as before), but the data goes the other way.

See, it can be done, but the changing page tables are a PITA. It's slow.

>With the same virtual address space for kernel and user, you
>don't need any of this stuff. The only reason we have special
>functions (macros) for copy to/from, is to protect the kernel
>from crashing when the user-mode caller gives it a bad address.

wrong - In either case, the parameters to the system call (and the
return values) have to be evaluated for proper usage and security.
That is NOT unique and can be done in many ways.

They provide the same protection as that provided by
other hardware. Even using page remapping will work, if implemented
properly. it just isn't as fast as using a single virtual mapping.

Been there, done that.

Multi-tasking real time systems do this a LOT - and because the
amount of data passed may be quite small it is frequently
more efficient. (largest I ever did was about 256 bytes - ocean going
autopilot/seismic surveys). The determining factor is:
1. correctness, 2. speed, 3. ease of implementation, 4. hardware
support.

>It all tasks were cooperative, you could use memcpy() perfectly
>fine (or rep movsl ; rep movsw ; rep movsb).

You still must verify that the source/destination are reasonably valid.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [e-mail]

Any opinions expressed are solely my own.