On Dec 2, 2009, at 2:42 PM, Roger A. Faulkner wrote:

> I am sponsoring this fast-track case for myself.
>
> No external/ABI interfaces are changing, so there is no  
> documentation change.
>
> The release binding is "minor",
> so it can be done in solaris_nevada (Solaris Next, OpenSolaris)
> (this will never be back-ported).
>
> DISCUSSION:
...

Roger,

I certainly agree some of this is implementation and doesn't matter.   
And from a technical perspective, because the current DTrace syscall  
provider advertises the sysent table names and not the sub-coded man  
page (2) view of system calls (something we intend to rectify  
someday), we marked those names as Private in our stability mechanism.

But from a practical perspective, I'm very uncomfortable with the *at  
part of this project, whereby extremely well-known fundamental names  
used extensively by users of DTrace based on long-standing  
fundamentals like syscall::open:entry just go away, essentially for no  
benefit.  (That is, we don't actually have any pressing need to add 74  
new system calls to the OS, to make use of this vast slot reclaiming)   
It just spuriously breaks people's DTrace scripts for no reason, and  
makes them harder to rewrite, since the *at variants have more  
complicated flags and whatnot.

It would seem that for those, you can simply put the equivalent  
wrapper you described in the kernel, rather than libc, thereby  
achieving the same effect of just making the bugs and code exist in  
one canonical function.

Is there any other benefit only achieved by removing those from the  
sysent table?  If not, my preference would be to leave 'open' and  
friends alone for now, resolving that with kernel function calls  
instead.  If we reach the point of needing the additional slot entries  
freed up by those, that work can be done along with a true man(2)- 
equivalent syscall provider.

-Mike

---
Mike Shapiro, Sun Microsystems Open Storage / Fishworks. blogs.sun.com/mws/

Reply via email to