Well I tried to mbuff in kernel, than use this for mbuff_alloc_at in user
space but to no avail, returned 0 as I recall. Can I expect a better
chance by append mem=xxM to the boot parameters than using
__va(ptr) in kernel and mmap("/dev/mem") in user instead?
Others ideas welcome if programable for Joe-Random-Not-Kernel-Hacker.
lothar
On Mon, Apr 09, 2001 at 05:42:13PM +0200, David Olofson wrote:
>
> AFAIK, kernel space normally maps it's memory in the high end of the 4 GB
> range (on x86), precisely in order to *avoid* collisions with user space
> mappings. (That way, you can avoid some linear->physic translation table
> swapping when entering kernel space; the mappnigs are always there, but just
> not accessible from user space.)
>
> I think it should theoretically possible to map almost any physical memory to
> any free region, whether in kernel space or in user space, but I can't see
> how it could be done with less than reserving a part of the linear address
> space globally. (If *any* task could replace that mapping, you'd be in
> trouble when the RTL thread tries to access the shared area...)
>
> It doesn't seem like a thing that would be explicitly supported, but there
> might be some shortcut.
>
> Changing the access flags on memory pages allocated from the kernel heap
> could work, I guess, but without some further hacking (changing those pages
> upon switches between tasks with access and other tasks), it would mean that
> *any* task gets access to the memory. Major security hole. :-)
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
