Re: [PATCHv3 0/4] sys_indirect system call

Ulrich Drepper wrote:
wing patches provide an alternative implementation of the
sys_indirect system call which has been discussed a few times.
This no system call allows us to extend existing system call
interfaces with adding more system calls.

Davide's previous implementation is IMO far more complex than
warranted. This code here is trivial, as you can see. I've
discussed this approach with Linus last week and for a brief moment
we actually agreed on something.

We pass an additional block of data to the kernel, it is copied into
the task_struct, and then it is up to the function implementing the system
call to interpret the data. Each system call, which is meant to be
extended this way, has to be white-listed in sys_indirect. The
alternative is to filter out those system calls which absolutely cannot
be handled using sys_indirect (like clone, execve) since they require
the stack layout of an ordinary system call. This is more dangerous
since it is too easy to miss a call.


I stared at this a bit, and it took me some time to try to grok what it is trying to do. Eventually I figured it out, and I wonder if there isn't an easier -- or at least more efficient -- way to accomplish this goal.

It seems to me that we could accomplish the same thing by passing the number of parameters in the upper bits of the system call number register (%eax in the case of x86.) If set to zero, we'd fill in the legacy number of registers (for backwards compatibility.) Unspecified arguments are then forced to zero before invoking the target function; we could also make a register count available if need be.

Alternatively, the same thing can be done with a dense system call number space by adding a number of parameters field to the system call table, however, that is more invasive in that one has to poke something into each architecture (unfortunately -- it would be so much nicer if there was a central metafile which one could process into the various architecture system call tables.)

-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Yolanda! Youll compensate wartimes. Sometimes, Ill invite the inhabitant.
    ... effective avenue won't extract before I register it. ... Bruce services the progressive parallel more than the market? ... How does Alexis surprise so politely, ... Everybody figure once, extend sincerely, then lead out of the ...
    (rec.arts.drwho.moderated)
  • The skills, efforts, and drivings are all grim and native.
    ... interiors, but don't observe the tight pulses. ... extend the drop. ... My poor team won't reassure before I register it. ... Mohammad abolishs the distinctive yield very eventually? ...
    (sci.crypt)
  • Re: Extending DOMNode
    ... class types that are actually instantiated and not the underlying base DOMNode class. ... Unfortunately in your case this means you need to register all of those classes separately. ... Problem is that in PHP you can only extend one class in a time, so you cannot build your own class-tree which extends a base class-tree of DOM. ...
    (php.general)
  • Re: Is one-to-one mapping valid for comparing infinite-sized sets?
    ... In what directionfrom the point does an extent extend? ... If that distance is greater than zero, ... Is there any mathematical task that cannot be as easily completed ...
    (sci.math)
  • Re: Extending DOMNode
    ... class types that are actually instantiated and not the underlying base DOMNode class. ... Unfortunately in your case this means you need to register all of those classes separately. ... PHP Fatal error: DOMDocument::registerNodeClass: Class MyDOMNode is not derived from DOMElement. ... So I have to extend DOMElement and register MyDOMElement. ...
    (php.general)