> > > The CPU doesn't support 64 bit pointers. Kind of makes it a bit
> > > inefficient to access the user memory if you have to make a system call
> > > every time. :)
> > Yes, but we do can use 24:32 referencse (as
> > pse36_extended_selectors:offset). Each process may own a ldt that allow
> > him to own several 4Gb segment : code, data, stack, kernel mem mapped,
> > librairies, shared mem (X11/dga -> fb mem and IPC shm).
>
> HOLY SH*! (sorry). You don't mean that for real, do you? This would
> completely break C and Unix and whatever else paradigm. If dealing
> with
Not true. This still could be valid C. Borlands (and every dos
compiler) do that for years, and yes it is possible to get right.
> pointers you'd have to know to which segment the pointer belongs: Is this
> a pointer to a user or lib function, is this a pointer to a variable on
> stack, userspace or in the lib. You could make the compiler use some
> larger pointers, but as the 24:32 is probably again not a unique mapping
> (because 24+32 > 36; I mean several selector:offset combinations refer to
> the same memory location) it will be a pain for pointer arithmetic.
Yes. So it would not break C and it would not break unix.
> Yes, I know, generations of real mode compilers worked this way, and it
> was a pain in the ass for anyone.
Agreed. This is not the way to go. But it is possible.
> > As this could broke a lot of soft, we may define a flag in ELF header
> > that select 2:2 split of ram or the new scheme.
>
> A lot of soft? It will break ANY C-program except special
> applications.
No. Correctly-written ANSI-C programs would still work.
> THEY need this cludge to deal with even the simplest applications, WE
> don't.
Well - and if we need it we should better buy ultrasparc.
Pavel
-- I'm really pavel@ucw.cz. Look at http://195.113.31.123/~pavel. Pavel Hi! I'm a .signature virus! Copy me into your ~/.signature, please!- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/