On Tue, May 22, 2007 at 08:28:28PM -0400, Mike Frysinger wrote:
> On 5/21/07, Paul Mundt <[email protected]> wrote:
> >On Mon, May 21, 2007 at 10:35:08AM -0400, Robin Getz wrote:
> >> On Mon 21 May 2007 06:09, Bryan Wu pondered:
> >> > Lots of update for 2.6.22-rc2 and tested on STAMP537 board.
> >> >
> >>
> >> One of the things I noticed when trying out 2.6.22-rc1, on blackfin was:
> >>
> >> CALL scripts/checksyscalls.sh
> >[snip syscalls]
> >>
> >> since there is noMMU, are we better:
> >> - putting stubs (return ENOSYS - give runtime errors), or
> >> - just ignore the errors - and give compile errors? (Is there any way
> >to put
> >> something into the syscall table, as not to get the warnings?)
> >
> >No, you'd be better of figuring out which ones you can support and which
> >ones you have to -ENOSYS. CONFIG_MMU=n is not a "get out of syscalls
> >free" card. Many of these have no dependency on CONFIG_MMU, anyways.
>
> when you say -ENOSYS, do you mean we need sys_foo() that simply does
> return -ENOSYS or do we just let the default syscall code go "__NR_foo
> is not registered, return -ENOSYS"
The checksyscalls.sh errors come from the fact you have missing
definitions in asm-blackfin/unistd.h, however, you still have reserved
slots for most of these syscalls (and explicit sys_ni_syscall wrapping in
the syscall table), just no __NR_foo definition.
It's also not clear which of these you are explicitly never going to
support versus the ones that simply haven't been implemented yet (ie,
kexec support, restartable system calls -- how do you even do
ppoll/pselect6 without supporting these?, and so on).
I would suggest simply defining the __NR_foo values based on the reserved
slots that they already occupy in order to silence these warnings, at
least that's a closer approximation of "we've actually looked at these
syscalls" than "new or otherwise unintentionally unimplemented", which is
what the script aims to help with.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
