>Well, depends... it would reduce the number of "active codepaths"
>between userland and kernel and _maybe_ (just raw guessing) lower the
>usage in the code case a bit (Ok... I guess the experts will now start
>to rip this statement into pieces... :-) ) ... or not. I am not sure
I don't think we're quite prepared to give up on all statically
linked executables (they will all break when we remove open et.al.
from the kernel syscall table).
I have some issues with the way we have currently implemented *at():
- seperate entry points in libc (good)
- mapping to a single entry point in the kernel (fsat, I think)
- then demultiplexing this again in the kernel
OTOH, having syscall table entry points for all of *stat64 also seems
illadvised.
Changing the calls so that the old entry becomes "<entry>at" would
be possible (but guarantees Solaris 2.x statically linked executable
breakage; not that we support that anyway, but it "mostly works" except
for a few syscalls we broke)
>Do you have any URL for the discussion ?
Somewhere in the Austin archives; I also think there was some confusion
about the leading "f"; I think it stood for "w/ flags" but other interpreted
it as "needless f which should be removed". (OTOH, that doesn't
explain "unlinkat" and clearly "fopenat()" would be wrong.
>Ok... and maybe I shouldn't worry too much since lots of the "older"
>systems get eliminated from my equation because they lack POSIX thread
>support... but I fear that some systems still don't have the /proc
>feature (which generates elephant-sized headaches right now (right after
>a reliable way to detect whether |fork()| behaves like |forkall()| or
>|fork1()|, a (portable) way to avoid the need to rely on |SIGCLD| to
>detect whether a child process terminates (e.g. imagine having two
>seperate shell instances within one process, both running on seperate
>threads... fun... ;-( )) etc.).
Of course, if something is *POSIX* fork() will behave like fork1().
(But on older Solaris releases this requires adding -lpthread.)
Casper
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
