Stubbing out unavailable syscalls?

[Bernhard Fischer]

On Thu, Feb 01, 2007 at 02:45:09PM +0100, Bernhard Fischer wrote:
>On Thu, Feb 01, 2007 at 01:31:18PM +0100, Joakim Tjernlund wrote:
>>O
>>> Well, do we -ENOSYS if something isn't available?
>>> If so, then we should rather
>>> #ifdef __NR_readahead
>>> [snip current code]
>>> #else
>>> ssize_t readahead(int fd, off_t offset, size_t count)
>>> {
>>> 	__set_errno(ENOSYS);
>>> 	return -1;
>>> }
>>> link_warning(readahead,"not available")
>>> #endif
>>> 
>>> Wondering if there should be a generic internal helper stub for
>>> the ENOSYS;ret -1 case..
>>
>>This can make cross compiling painful since you can't tell if
>>readahead is present or not.
>>On the other hand, a well behaved app will handle this dynamically ...
>
>Either way, behaviour should imho be consistent, and it is not, from a
>quick grep for ENOSYS. Didn't really look, admittedly.
>
>Not stubbing unsupported functions out sounds smaller. Deciding what
>route to take, either to stub them out or making them not available
>isn't my call, though.

[replying to this old thread]

So.. what do people think should be done in this respect?

I'm attaching a proposal that allows for conveniently adding stubs by
doing this:
--- 8< ---
#include <bits/syscall-stub.h>
#define __SYSCALL_STUB __NR_pivot_root
#include <sys/syscall.h>

int pivot_root(const char *new_root, const char *put_old);
_syscall2(int, pivot_root, const char *, new_root, const char *, put_old);
--- 8< ---
instead of manually providing a __set_errno(ENOSYS);return -1; stub

It converts a few conditional syscalls to this proposed scheme as an
example.
This way we could even have a config-option that decides if there should
be any stubs or none (not talking about alternative impls, they are of
no interrest for now).

Opinions?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uClibc-0.9.29.syscall-stubs.02a.diff
Type: text/x-diff
Size: 8932 bytes
Desc: not available
Url : http://busybox.net/lists/uclibc/attachments/20080520/075827e2/attachment.diff