I don't see how it's much different, actually. Just as ld.so must
ignore LD_* environment variables for setuid programmes, MAP_INHERIT
can be ignored for setuid. And with MAP_INHERIT, you don't have to
worry about ld.so being replaced with something that *doesn't* ignore
LD_*.
So, sure, you have a few more calls to mmap(2) libc and syscall.so and
such. Once for each switch to a privileged state. That's a minor loss.
It's easy enough for each programme to check if there are any
inherited mappings: just use the new syscall.
> Also, it would make it impossible to use the global TLB trick, but
> that may not be worth worrying about.
Why not? If the shared areas are mapped to the same virtual address,
we can keep the same TLB entry.
> So I think it's a great notion, but it just sucks in real life. And
> it wouldn't allow the interesting things like gettimeofday() that
> really only the kernel can do: you can calibrate the clock in user
> space, but you cannot do things like automatically re-calibrate
> after a suspend event etc, which is critical on laptops and will be
> even more so with the new dual-frequency coppermine CPU's from
> Intel... (were not only the base time changes, but the frequency of
> the clock changes too).
I'm not suggesting that we don't have a global page. But I think that
global page should only have *data*. No code.
> There _are_ a lot of issues like this where the kernel really knows
> things that user space can not easily know.
Sure. But you're talking about two different things. One is global
code for syscall entry points, which can be done from user-space (with
MAP_INHERIT). The other is global kernel data, which obviously is a
kernel thing.
Two different things, two simple mechanisms, rather than a single,
bigger mechanism.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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/