Stubbing out unavailable syscalls?

[Joakim Tjernlund]

> -----Original Message-----
> From: uclibc-bounces at uclibc.org [mailto:uclibc-bounces at uclibc.org] On Behalf Of Bernhard Fischer
> Sent: den 20 maj 2008 19:49
> To: uclibc at uclibc.org
> Subject: Stubbing out unavailable syscalls?
> 
> 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?

Still think ease of cross compiling is more important than stubs.
Are there any apps that is broken due to missing stubs?

I can live with stubs behind a config option, default off. 

     Jocke