Why is CONFIG_FHANDLE an option??

Why is CONFIG_FHANDLE an option??

[Jesper Juhl]

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?
I'd say we should just add them unconditionally or not have them at all. 
One should be able to say that "since Linux 3.0 these syscalls are 
available", not "since Linux 3.0 these syscalls *may* be available"... 
We'll just end up in a situation where some distributors enable the 
syscalls, some don't and it'll all be a mess for users... either we have 
them or we don't.

Ok, long rant, sorry about that... but really; why are they optional??


-- 
Jesper Juhl <jj@chaosbits.net>       http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.

Re: Why is CONFIG_FHANDLE an option??

[Al Viro]

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.

Re: Why is CONFIG_FHANDLE an option??

[Jesper Juhl]

On Fri, 10 Jun 2011, Al Viro wrote:

> 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.

Well, sometimes you may want to make it a requirement that whomever 
deploys your software runs Linux X.Y.Z or whatever.. You don't want to 
make it "run Linux X.Y.Z with syscalls A, B, C enabled" etc.

Sometimes it's nice to draw lines in sand and just say "from this day 
forward we support so and so".


-- 
Jesper Juhl <jj@chaosbits.net>       http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.

Re: Why is CONFIG_FHANDLE an option??

[Al Viro]

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...

Re: Why is CONFIG_FHANDLE an option??

[Jesper Juhl]

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@chaosbits.net>       
http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.

Re: Why is CONFIG_FHANDLE an option??

[Al Viro]

On Sat, Jun 11, 2011 at 12:42:50AM +0200, Jesper Juhl wrote:

> 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...

There's fanotify in that pile.  Consider that bright idea *strongly* NAKed.

Re: Why is CONFIG_FHANDLE an option??

[Alexey Dobriyan]

On Fri, Jun 10, 2011 at 11:39:55PM +0100, Al Viro wrote:
> On Sat, Jun 11, 2011 at 12:14:02AM +0200, Jesper Juhl wrote:
> > 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?

To avoid situations like "I need to use a program but suddenly
it requires system call which I compiled out a month before and now
I need to reboot like an idiot".

splice(2) wasn't given config option despite several times bigger .o
file compared to fshandle+exportfs.

So let's say it was always somewhat arbitrary decision.