From: "H. Peter Anvin" <hpa@zytor.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
Matthew Wilcox <matthew@wil.cx>,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-arch@vger.kernel.org, linux@arm.linux.org.uk,
dhowells@redhat.com, ysato@users.sourceforge.jp,
tony.luck@intel.com, geert@linux-m68k.org, zippel@linux-m68k.org,
gerg@uclinux.org, schwidefsky@de.ibm.com,
heiko.carstens@de.ibm.com, jdike@addtoit.com, tglx@linutronix.de,
mingo@redhat.com
Subject: Re: [PATCH 1/3] generic sys_old_select
Date: Fri, 08 Jan 2010 14:22:41 -0800 [thread overview]
Message-ID: <4B47B031.5000406@zytor.com> (raw)
In-Reply-To: <20100108093137.GA28722@lst.de>
On 01/08/2010 01:31 AM, Christoph Hellwig wrote:
> On Wed, Jan 06, 2010 at 05:41:09PM +0000, Al Viro wrote:
>> Actually, I'd be a lot happier if we had lib/syscall/old_select.c, instead
>> of cluttering fs/select.c with that. Objections?
>
> If we do that let's do it consistantly for various old syscalls, not
> an odd one out.
Yes, and it would be a good idea to do so, rather than hiding all these
compatibility calls in all kind of random places.
There is, however, a reason *not* to do it which should be carefully
considered: by co-locating the compatibility version with the modern
version, it gets access to static functions that are part of the
implementation of the modern version. If we move the compatibility
versions out, it may entail having to export those statics.
-hpa
next prev parent reply other threads:[~2010-01-08 22:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-06 17:21 [PATCH 1/3] generic sys_old_select Christoph Hellwig
2010-01-06 17:21 ` Christoph Hellwig
2010-01-06 17:32 ` Matthew Wilcox
2010-01-06 17:34 ` Christoph Hellwig
2010-01-06 17:41 ` Al Viro
2010-01-06 17:47 ` H. Peter Anvin
2010-01-08 9:31 ` Christoph Hellwig
2010-01-08 22:22 ` H. Peter Anvin [this message]
2010-01-10 4:49 ` Al Viro
2010-01-06 17:44 ` David Howells
-- strict thread matches above, loose matches on Subject: below --
2010-01-08 22:52 Andreas Mohr
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=4B47B031.5000406@zytor.com \
--to=hpa@zytor.com \
--cc=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=geert@linux-m68k.org \
--cc=gerg@uclinux.org \
--cc=hch@lst.de \
--cc=heiko.carstens@de.ibm.com \
--cc=jdike@addtoit.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=matthew@wil.cx \
--cc=mingo@redhat.com \
--cc=schwidefsky@de.ibm.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=viro@ZenIV.linux.org.uk \
--cc=ysato@users.sourceforge.jp \
--cc=zippel@linux-m68k.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).