From: Greg Ungerer <gerg@snapgear.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
Linux/m68k <linux-m68k@lists.linux-m68k.org>,
uClinux list <uclinux-dev@uclinux.org>
Subject: Re: [PATCH] m68k: Merge mmu and non-mmu versions of sys_call_table
Date: Tue, 19 Apr 2011 14:32:34 +1000 [thread overview]
Message-ID: <4DAD1062.2020309@snapgear.com> (raw)
In-Reply-To: <201104172213.01258.arnd@arndb.de>
On 18/04/11 06:13, Arnd Bergmann wrote:
> On Wednesday 13 April 2011, Geert Uytterhoeven wrote:
>> When comparing this to the MMU comments in include/asm-generic/unistd.h,
>> I noticed this:
>>
>> M68knommu does have:
>> - sys_mbind
>> - sys_get_mempolicy
>> - sys_set_mempolicy
>> - sys_migrate_pages
>> - sys_move_pages
>
> scripts/checksyscalls.sh ignores these on NOMMU, so I did not list them.
> Are there any NOMMU system with NUMA support?
Certainly no m68k/ColdFire ones...
> If so, what are these
> syscalls supposed to do in that case? I assume that they don't actually
> change the physical location of a virtual address.
>
> Since the unistd.h file is shared with m68k, I see nothing wrong here,
> they should simply get stubbed out like the other NOMMU syscalls (swapon,
> mprotect, msync, ...)
I have no objection to changing these to be sys_ni_syscall for the
CONFIG_MMU=n case of m68k. I am pretty sure they will never have
been used in any way on m68knommu systems. (It does look like uClibc
for example does support these even on no-mmu systems though. I just
don't think they will have actually been used by anyone).
>> - sys_fork, although it returns -EINVAL, not -ENOSYS
I can't recall why it is that way :-)
For one thing uClibc doesn't even generate a library symbol for it.
So the only way someone would be able to get to it normally on an
m68knommu system is to code the raw system call. And even then all
they will ever get is a fail. I doubt the change in errno return
type would be a problem.
I have no problem with being consistent with asm-generic/unistd.h,
and stubbing this to a sys_ni_syscall as well.
>> M68knommu does not implement:
>> - sys_mremap
>> - sys_nfsservct
>
> Shouldn't you get a warning about these from scripts/checksyscalls.sh ?
It doesn't complain.
> mremap should really work, except for MREMAP_FIXED, as documented in mm/nommu.c.
> nfsservctl is probably not needed, but I see no reason to leave it out either.
They should work exactly the same as any other non-mmu arch.
I just compile tested with those enabled (as per asm-generic/unistd.h)
and it worked fine. So I would be happy to see those removed from the
stub list for m68k/m68knommu.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
next prev parent reply other threads:[~2011-04-19 4:32 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-06 20:33 [PATCH] m68k: Merge mmu and non-mmu versions of sys_call_table Geert Uytterhoeven
2011-04-06 22:05 ` [uClinux-dev] " Philippe De Muyter
[not found] ` <20110406220510.GA17350@frolo.macqel>
2011-04-07 0:53 ` Greg Ungerer
2011-04-07 2:12 ` Gavin Lambert
[not found] ` <000301cbf4c9$40339fc0$c09adf40$@com>
2011-04-07 2:43 ` Greg Ungerer
2011-04-07 3:13 ` Gavin Lambert
2011-04-07 4:14 ` Greg Ungerer
[not found] ` <4D9D3A28.9060104@snapgear.com>
2011-04-07 7:04 ` Geert Uytterhoeven
2011-04-07 8:29 ` Andreas Schwab
2011-04-07 8:35 ` Philippe De Muyter
2011-04-07 8:39 ` Andreas Schwab
2011-04-13 18:03 ` Geert Uytterhoeven
2011-04-07 1:53 ` Greg Ungerer
2011-04-13 18:16 ` Geert Uytterhoeven
2011-04-17 20:13 ` Arnd Bergmann
2011-04-19 4:32 ` Greg Ungerer [this message]
2011-04-19 8:21 ` Arnd Bergmann
2011-04-19 8:30 ` Geert Uytterhoeven
2011-04-19 8:52 ` Arnd Bergmann
2011-04-19 12:26 ` Greg Ungerer
2011-05-04 18:37 Geert Uytterhoeven
2011-05-04 18:37 ` Geert Uytterhoeven
2011-05-04 22:18 ` Greg Ungerer
2011-05-04 22:18 ` Greg Ungerer
2011-05-05 6:24 ` Arnd Bergmann
2011-05-05 6:24 ` Arnd Bergmann
2011-05-05 7:55 ` Greg Ungerer
2011-05-05 7:55 ` Greg Ungerer
2011-05-05 18:44 ` Geert Uytterhoeven
2011-05-05 18:44 ` Geert Uytterhoeven
2011-05-05 20:37 ` Arnd Bergmann
2011-05-05 20:37 ` Arnd Bergmann
2011-05-06 5:11 ` Geert Uytterhoeven
2011-05-06 5:11 ` Geert Uytterhoeven
2011-05-06 8:24 ` Andreas Schwab
2011-05-06 8:24 ` Andreas Schwab
2011-05-06 18:56 ` Geert Uytterhoeven
2011-05-06 18:56 ` Geert Uytterhoeven
2011-05-05 20:39 ` Mikael Pettersson
2011-05-07 8:34 ` Geert Uytterhoeven
2011-05-07 8:34 ` Geert Uytterhoeven
2011-05-07 13:16 ` Mikael Pettersson
2011-10-23 9:53 ` Andreas Schwab
2011-10-23 12:20 ` Geert Uytterhoeven
2011-10-23 14:59 ` Andreas Schwab
2011-10-23 14:59 ` Andreas Schwab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DAD1062.2020309@snapgear.com \
--to=gerg@snapgear.com \
--cc=arnd@arndb.de \
--cc=geert@linux-m68k.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=uclinux-dev@uclinux.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.