From: Greg KH <greg@kroah.com>
To: blaisorblade@yahoo.it
Cc: torvalds@osdl.org, akpm@osdl.org,
user-mode-linux-devel@lists.sourceforge.net, stable@kernel.org,
jdike@addtoit.com, linux-kernel@vger.kernel.org
Subject: [uml-devel] Re: [stable] [patch 3/8] uml: quick fix syscall table [urgent]
Date: Wed, 30 Mar 2005 11:05:09 -0800 [thread overview]
Message-ID: <20050330190509.GA17602@kroah.com> (raw)
In-Reply-To: <20050330173348.63741EFE76@zion>
On Wed, Mar 30, 2005 at 07:33:48PM +0200, blaisorblade@yahoo.it wrote:
>
> CC: <stable@kernel.org>
>
> *) Uml 2.6.11 does not compile with gcc 2.95.4 because some entries are
> duplicated, and that GCC does not accept this (unlike gcc 3). Plus various
> other bugs in the syscall table definitions:
>
> *) 223 is a syscall hole (i.e. ni_syscall) only on i386, on x86_64 it's a
> valid syscall (thus a duplicated one).
>
> *) __NR_vserver must be only once with sys_ni_syscall, and not multiple
> times with different values!
>
> *) syscalls duplicated in SUBARCHs and in common files (thus assigning twice
> to the same array entry and causing the GCC 2.95.4 failure mentioned above):
> sys_utimes, which is common, and sys_fadvise64_64, sys_statfs64,
> sys_fstatfs64, which exist only on i386.
>
> *) syscalls duplicated in each SUBARCH, to put in common files:
> sys_remap_file_pages, sys_utimes, sys_fadvise64
>
> *) 285 is a syscall hole (i.e. ni_syscall) only on i386, on x86_64 the range
> does not arrive to that point.
>
> *) on x86_64, the macro name is __NR_kexec_load and not __NR_sys_kexec_load.
> Use the correct name in either case.
>
> Note: as you can see, part of the syscall table definition in UML is
> arch-independent (with everywhere defined syscalls), and part is
> arch-dependant. This has created confusion (some syscalls are listed in both
> places, some in the wrong one, some are wrong on one arch or another).
>
> Also, as add-ons:
>
> *) uses __va_copy instead of va_copy since some old versions of gcc (2.95.4
> for instance) don't accept va_copy.
>
> *) some whitespace cleanups in the syscall table (if you don't like them, feel
> free to remove them).
For this to be considered for the -stable tree, can you remove the
whitespace cleanups, and break this up into different patches for the
different things you are doing (one thing per patch please.)
thanks,
greg k-h
-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <greg@kroah.com>
To: blaisorblade@yahoo.it
Cc: torvalds@osdl.org, akpm@osdl.org,
user-mode-linux-devel@lists.sourceforge.net, stable@kernel.org,
jdike@addtoit.com, linux-kernel@vger.kernel.org
Subject: Re: [stable] [patch 3/8] uml: quick fix syscall table [urgent]
Date: Wed, 30 Mar 2005 11:05:09 -0800 [thread overview]
Message-ID: <20050330190509.GA17602@kroah.com> (raw)
In-Reply-To: <20050330173348.63741EFE76@zion>
On Wed, Mar 30, 2005 at 07:33:48PM +0200, blaisorblade@yahoo.it wrote:
>
> CC: <stable@kernel.org>
>
> *) Uml 2.6.11 does not compile with gcc 2.95.4 because some entries are
> duplicated, and that GCC does not accept this (unlike gcc 3). Plus various
> other bugs in the syscall table definitions:
>
> *) 223 is a syscall hole (i.e. ni_syscall) only on i386, on x86_64 it's a
> valid syscall (thus a duplicated one).
>
> *) __NR_vserver must be only once with sys_ni_syscall, and not multiple
> times with different values!
>
> *) syscalls duplicated in SUBARCHs and in common files (thus assigning twice
> to the same array entry and causing the GCC 2.95.4 failure mentioned above):
> sys_utimes, which is common, and sys_fadvise64_64, sys_statfs64,
> sys_fstatfs64, which exist only on i386.
>
> *) syscalls duplicated in each SUBARCH, to put in common files:
> sys_remap_file_pages, sys_utimes, sys_fadvise64
>
> *) 285 is a syscall hole (i.e. ni_syscall) only on i386, on x86_64 the range
> does not arrive to that point.
>
> *) on x86_64, the macro name is __NR_kexec_load and not __NR_sys_kexec_load.
> Use the correct name in either case.
>
> Note: as you can see, part of the syscall table definition in UML is
> arch-independent (with everywhere defined syscalls), and part is
> arch-dependant. This has created confusion (some syscalls are listed in both
> places, some in the wrong one, some are wrong on one arch or another).
>
> Also, as add-ons:
>
> *) uses __va_copy instead of va_copy since some old versions of gcc (2.95.4
> for instance) don't accept va_copy.
>
> *) some whitespace cleanups in the syscall table (if you don't like them, feel
> free to remove them).
For this to be considered for the -stable tree, can you remove the
whitespace cleanups, and break this up into different patches for the
different things you are doing (one thing per patch please.)
thanks,
greg k-h
next prev parent reply other threads:[~2005-03-30 19:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-30 17:33 [uml-devel] [patch 3/8] uml: quick fix syscall table [urgent] blaisorblade
2005-03-30 17:33 ` blaisorblade
2005-03-30 19:05 ` Greg KH [this message]
2005-03-30 19:05 ` [stable] " Greg KH
2005-04-01 20:45 ` [uml-devel] " Blaisorblade
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=20050330190509.GA17602@kroah.com \
--to=greg@kroah.com \
--cc=akpm@osdl.org \
--cc=blaisorblade@yahoo.it \
--cc=jdike@addtoit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@kernel.org \
--cc=torvalds@osdl.org \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/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.