All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Jesper Juhl <jj@chaosbits.net>
Cc: linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Jonas Gorski <jonas.gorski@gmail.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Subject: Re: Why is CONFIG_FHANDLE an option??
Date: Fri, 10 Jun 2011 23:39:55 +0100	[thread overview]
Message-ID: <20110610223955.GA11521@ZenIV.linux.org.uk> (raw)
In-Reply-To: <alpine.LNX.2.00.1106110001180.21722@swampdragon.chaosbits.net>

On Sat, Jun 11, 2011 at 12:14:02AM +0200, Jesper Juhl wrote:
> Hello
> 
> I just configured a new kernel based on a recent git checkout and when I 
> had copied in my old configuration and did a "make oldconfig"I was greeted 
> with
> 
>     open by fhandle syscalls (FHANDLE) [N/y/?] (NEW)
> 
> Ok, so I read the help text description and learn that it's about two new 
> syscalls - open_by_handle_at(2) and name_to_handle_at(2).
> 
> My first thought at this point was "why are new syscalls even an option"?
> 
> Syscalls are in my oppinion ABI - having optional syscalls is just about 
> as bad as removing a syscall. It basically means that users cannot know if 
> the syscall is there and will need to test (it's bad enough having to 
> check the kernel version, having to check for specific syscalls as well 
> is just, well, annoying at best). 
> 
> Why are we making these optional?

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.

  reply	other threads:[~2011-06-10 22:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-10 22:14 Why is CONFIG_FHANDLE an option?? Jesper Juhl
2011-06-10 22:39 ` Al Viro [this message]
2011-06-10 22:38   ` Jesper Juhl
2011-06-10 22:47   ` Al Viro
2011-06-10 22:42     ` Jesper Juhl
2011-06-10 22:58       ` Al Viro
2011-06-10 23:10   ` Alexey Dobriyan

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=20110610223955.GA11521@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=jj@chaosbits.net \
    --cc=jonas.gorski@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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.