>>syscall bindings. My example was about code using the predefined syscall
>>number for new functions on an older kernel where those functions don't
>>exist, but where they overlap with the older dynamic syscall numbers. In
>>short, the patch is safe for code that uses the lazy binding, but it can
>>still overlap with future syscall numbers and code that doesn't use the lazy
>>binding but instead uses predefined numbers.
>>
>
> Now I follow you. So if Linus takes that patch he needs to allocate a block
> of per architecture dynamic syscall number space for it to use. Negative
> syscall numbers seem the most promising approach ?
>
>
Something like that. It needs to be a large enough range to reasonably
support the maximum number of expected syscalls that could possibly be in
testing at one time (which is a total guesstimate if you ask me), and it
should hopefully be up high so that we aren't allocating new numbers around
it. However, I think it needs to be allocated *regardless* of whether Linus
takes the patch into his kernel. Even if the patch is simply used outside
Linus's kernel, it still needs the allocation to truly be safe.
--Doug Ledford <dledford@redhat.com> http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/