[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.00.1106110040370.21722@swampdragon.chaosbits.net>
Date: Sat, 11 Jun 2011 00:42:50 +0200 (CEST)
From: Jesper Juhl <jj@...osbits.net>
To: Al Viro <viro@...IV.linux.org.uk>
cc: linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Jonas Gorski <jonas.gorski@...il.com>,
"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Subject: Re: Why is CONFIG_FHANDLE an option??
On Fri, 10 Jun 2011, Al Viro wrote:
> On Fri, Jun 10, 2011 at 11:39:55PM +0100, Al Viro wrote:
>
> > Why not? Software needs to test *anyway*, since it might run on earlier
> > kernels. And "does that syscall return -ENOSYS" is self-documenting,
> > while "is the version higher than $MAGIC_NUMBER" is *not*. Especially since
> > there's such thing as backports.
> >
> > If you need to check that syscall is there, _check_ _it_. Don't breed
> > dependencies on version numbers.
>
> PS: we have BSD_PROCESS_ACCT doing pretty much the same kind of thing.
> And SYSVIPC. And POSIX_MQUEUE. And there's nfsservctl(2), also
> config-dependent. And eventfd(2), and inotify syscalls, etc.
>
> There is such thing as optional system calls. Always had been. Deal
> with that...
Yes, I'm aware of that. Doesn't mean we have to make things worse.
Just because we've had optional syscalls in the past doesn't mean we have
to add more, nor that the existing ones were a good idea. IMHO they should
be removed as options and just included unconditionally - not too late to
correct this...
-- Jesper Juhl <jj@...osbits.net>
http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists