The naming of at()s is a difficult matter

The naming of at()s is a difficult matter

[H. Peter Anvin]

I have noticed that the new ...at() system calls are named in what
appears to be a completely haphazard fashion.  In Unix system calls,
an f- prefix means it operates on a file descriptor; the -at suffix (a
prefix would have been more consistent, but oh well) similarly
indicates it operates on a (directory fd, pathname) pair.

However, some system calls, in particular fchownat, futimesat,
fchmodat and faccessat add the f- prefix for what appears to be
absolutely no good reason.  Logically, these system calls should be
named chownat, utimesat, chmodat, and accessat.

I understand some of this braindamage comes from Solaris, but some of
these calls do not.  We should avoid it if at all possible, and I
would recommend at least introducing aliases with the sane names.

         -hpa

Re: The naming of at()s is a difficult matter

[Jan Engelhardt]

>
> I have noticed that the new ...at() system calls are named in what
> appears to be a completely haphazard fashion.  In Unix system calls,
> an f- prefix means it operates on a file descriptor; the -at suffix (a
> prefix would have been more consistent, but oh well) similarly
> indicates it operates on a (directory fd, pathname) pair.
>
shmat operates on dirfd/pathname?


Jan Engelhardt
-- 

Re: The naming of at()s is a difficult matter

[H. Peter Anvin]

Jan Engelhardt wrote:
>>I have noticed that the new ...at() system calls are named in what
>>appears to be a completely haphazard fashion.  In Unix system calls,
>>an f- prefix means it operates on a file descriptor; the -at suffix (a
>>prefix would have been more consistent, but oh well) similarly
>>indicates it operates on a (directory fd, pathname) pair.
> 
> shmat operates on dirfd/pathname?
> 

Convention collision.  They unfortunately happen (yet another reason the 
-at convention was ill choosen); another pretty bad clash is the f- 
prefix for use on file descriptors versus use on FILE *...

	-hpa

Re: The naming of at()s is a difficult matter

[Joerg Schilling]

Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> >
> > I have noticed that the new ...at() system calls are named in what
> > appears to be a completely haphazard fashion.  In Unix system calls,
> > an f- prefix means it operates on a file descriptor; the -at suffix (a
> > prefix would have been more consistent, but oh well) similarly
> > indicates it operates on a (directory fd, pathname) pair.
> >
> shmat operates on dirfd/pathname?

Do you have a better proposal for naming the interfaces?

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: The naming of at()s is a difficult matter

[H. Peter Anvin]

Joerg Schilling wrote:
> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> 
> 
>>>I have noticed that the new ...at() system calls are named in what
>>>appears to be a completely haphazard fashion.  In Unix system calls,
>>>an f- prefix means it operates on a file descriptor; the -at suffix (a
>>>prefix would have been more consistent, but oh well) similarly
>>>indicates it operates on a (directory fd, pathname) pair.
>>>
>>
>>shmat operates on dirfd/pathname?
> 
> 
> Do you have a better proposal for naming the interfaces?
> 

Isn't it obvious?  Drop the misleading f- prefixes.

	-hpa

Re: The naming of at()s is a difficult matter

[Jan Engelhardt]

>> > I have noticed that the new ...at() system calls are named in what
>> > appears to be a completely haphazard fashion.  In Unix system calls,
>> > an f- prefix means it operates on a file descriptor; the -at suffix (a
>> > prefix would have been more consistent, but oh well) similarly
>> > indicates it operates on a (directory fd, pathname) pair.
>> >
>> shmat operates on dirfd/pathname?
>
>Do you have a better proposal for naming the interfaces?
>

chownfn maybe. (fd + name)



Jan Engelhardt
-- 

Re: The naming of at()s is a difficult matter

[Joerg Schilling]

Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

>
> >> > I have noticed that the new ...at() system calls are named in what
> >> > appears to be a completely haphazard fashion.  In Unix system calls,
> >> > an f- prefix means it operates on a file descriptor; the -at suffix (a
> >> > prefix would have been more consistent, but oh well) similarly
> >> > indicates it operates on a (directory fd, pathname) pair.
> >> >
> >> shmat operates on dirfd/pathname?
> >
> >Do you have a better proposal for naming the interfaces?
> >
>
> chownfn maybe. (fd + name)

I am not shure if this would match the rules from the Opengroup.
Solaris has these interfaces since at least 5 years.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: The naming of at()s is a difficult matter

[H. Peter Anvin]

Joerg Schilling wrote:
> 
> I am not shure if this would match the rules from the Opengroup.
> Solaris has these interfaces since at least 5 years.
> 

Surely you're not suggesting that TOG's job is to rubber-stamp bad 
Solaris decisions...

	-hpa

Re: The naming of at()s is a difficult matter

[Matthew Frost]

--- "H. Peter Anvin" <hpa@zytor.com> wrote:

> Joerg Schilling wrote:
> > 
> > I am not shure if this would match the rules from the Opengroup.
> > Solaris has these interfaces since at least 5 years.
> > 
> 
> Surely you're not suggesting that TOG's job is to rubber-stamp bad 
> Solaris decisions...

No, he's suggesting that precedent should apply across unixen.  It makes
sense to Joerg, who programs for the lot of them like they share object
inheritance.  This is sometimes more problematic than others (vis a vis
cdrecord).  Joerg is disinclined to support the kind of compulsive
re-engineering that Linus encourages, even though you might do it because
it would make more sense re-engineered a certain way.  If I've understood
correctly (and charitably), he prefers compatibility over novelty.

I myself like functional novelty over conformant compatibility in the
adiaphora.

Matt

> 
> 	-hpa
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: The naming of at()s is a difficult matter

[Joerg Schilling]

"H. Peter Anvin" <hpa@zytor.com> wrote:

> Joerg Schilling wrote:
> > 
> > I am not shure if this would match the rules from the Opengroup.
> > Solaris has these interfaces since at least 5 years.
> > 
>
> Surely you're not suggesting that TOG's job is to rubber-stamp bad 
> Solaris decisions...

Are you interested in forcing Solaris to change all interfaces?


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: The naming of at()s is a difficult matter

[H. Peter Anvin]

Joerg Schilling wrote:
>>
>>Surely you're not suggesting that TOG's job is to rubber-stamp bad 
>>Solaris decisions...
> 
> Are you interested in forcing Solaris to change all interfaces?
> 

In this case, I think it would be entirely appropriate.  It's hardly a 
hardship to maintain the legacy names for backwards compatibility; since 
those names are nonsensical it is unlikely they'll ever want to be 
claimed, in which case they can be maintained indefinitely.

However, I would find it much, much worse if names that are *actively 
misleading and confusing* to the programmer would be included in an 
international standard and therefore forced upon the rest of the world 
forever.

	-hpa

Re: The naming of at()s is a difficult matter

[Jan Engelhardt]

>> >Do you have a better proposal for naming the interfaces?
>>
>> chownfn maybe. (fd + name)
>
>I am not shure if this would match the rules from the Opengroup.
>Solaris has these interfaces since at least 5 years.
>
This is not the cdrecord thread so Solaris is a no-go in this very one.



Thank you,
Jan Engelhardt
-- 
| Software Engineer and Linux/Unix Network Administrator
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/

Re: The naming of at()s is a difficult matter

[H. Peter Anvin]

Jan Engelhardt wrote:
>>>>Do you have a better proposal for naming the interfaces?
>>>
>>>chownfn maybe. (fd + name)
>>
>>I am not shure if this would match the rules from the Opengroup.
>>Solaris has these interfaces since at least 5 years.
> 
> This is not the cdrecord thread so Solaris is a no-go in this very one.
> 

FWIW, I think the -at() suffix is just fine, and well established by now 
(yes, there is shmat, but the SysV shared memory interfaces are bizarre 
to begin with -- hence POSIX shared memory which has real names.)

What I object to is the random, meaningless and misleading application 
of the f- suffix.

	-hpa

Re: The naming of at()s is a difficult matter

[Jan Engelhardt]

>> > > > Do you have a better proposal for naming the interfaces?
>> > > chownfn maybe. (fd + name)
>> > I am not shure if this would match the rules from the Opengroup.
>> > Solaris has these interfaces since at least 5 years.
>> This is not the cdrecord thread so Solaris is a no-go in this very one.
>
> FWIW, I think the -at() suffix is just fine, and well established by now (yes,
> there is shmat, but the SysV shared memory interfaces are bizarre to begin with
> -- hence POSIX shared memory which has real names.)
>
Yep. Someday, Linux - or rather glibc! for that matter, as it is the one 
which translates FUNCTIONNAME() into a syscall -- will be like the Windows 
API. Full of compatibility stuff. And you can't do anything about it :)


Jan Engelhardt
-- 

Re: The naming of at()s is a difficult matter

[Joerg Schilling]

"H. Peter Anvin" <hpa@zytor.com> wrote:

> >>>>Do you have a better proposal for naming the interfaces?
> >>>
> >>>chownfn maybe. (fd + name)
> >>
> >>I am not shure if this would match the rules from the Opengroup.
> >>Solaris has these interfaces since at least 5 years.
...

> FWIW, I think the -at() suffix is just fine, and well established by now 
> (yes, there is shmat, but the SysV shared memory interfaces are bizarre 
> to begin with -- hence POSIX shared memory which has real names.)
>
> What I object to is the random, meaningless and misleading application 
> of the f- suffix.

This is what I would concur.

I could live with the meaningless f- prefixes being removed for the POSIX
variant of the interface.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: The naming of at()s is a difficult matter

[Joerg Schilling]

Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> >> >Do you have a better proposal for naming the interfaces?
> >>
> >> chownfn maybe. (fd + name)
> >
> >I am not shure if this would match the rules from the Opengroup.
> >Solaris has these interfaces since at least 5 years.
> >
> This is not the cdrecord thread so Solaris is a no-go in this very one.

I encourage you to read a mail before you answer to it.
This may help you to avoid writing incorrect replies.



Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: The naming of at()s is a difficult matter

[Jim Meyering]

"H. Peter Anvin" <hpa@zytor.com> wrote:
> I have noticed that the new ...at() system calls are named in what
> appears to be a completely haphazard fashion.  In Unix system calls,
> an f- prefix means it operates on a file descriptor; the -at suffix (a
> prefix would have been more consistent, but oh well) similarly
> indicates it operates on a (directory fd, pathname) pair.
>
> However, some system calls, in particular fchownat, futimesat,
> fchmodat and faccessat add the f- prefix for what appears to be
> absolutely no good reason.  Logically, these system calls should be
> named chownat, utimesat, chmodat, and accessat.
>
> I understand some of this braindamage comes from Solaris, but some of
> these calls do not.  We should avoid it if at all possible, and I
> would recommend at least introducing aliases with the sane names.

This has bothered me, too.
But what would the semantics be?  Using an alias named `chownat'
to get lchown-like functionality (with the AT_SYMLINK_NOFOLLOW flag)
seems undesirable.

If we're considering aliases,
then how about a pair of `f'-less names for each of the f*at
names.  E.g., chownat and lchownat corresponding to the use (or not)
of AT_SYMLINK_NOFOLLOW in the last parameter of an fchownat function call.

Here's some code from coreutils/lib/openat.h:

  /* Using these function names makes application code
     slightly more readable than it would be with
     fchownat (..., 0) or fchownat (..., AT_SYMLINK_NOFOLLOW).  */
  static inline int
  chownat (int fd, char const *file, uid_t owner, gid_t group)
  {
    return fchownat (fd, file, owner, group, 0);
  }

  static inline int
  lchownat (int fd, char const *file, uid_t owner, gid_t group)
  {
    return fchownat (fd, file, owner, group, AT_SYMLINK_NOFOLLOW);
  }

  static inline int
  chmodat (int fd, char const *file, mode_t mode)
  {
    return fchmodat (fd, file, mode, 0);
  }

  static inline int
  lchmodat (int fd, char const *file, mode_t mode)
  {
    return fchmodat (fd, file, mode, AT_SYMLINK_NOFOLLOW);
  }

[Note that afaik, faccessat is available only in glibc so far. ]
Unfortunately, this doesn't generalize as well to faccessat,
which has four (not just two) possible values of its last parameter.
Those correspond to settings of the AT_SYMLINK_NOFOLLOW and AT_EACCESS
bits.  AT_EACCESS means faccessat checks for access by the effective IDs
rather than by the real IDs.

With faccessat, we'd need 4 different names, e.g.,

  elaccessat or leaccessat
  ulaccessat or luaccessat
  eaccessat
  uaccessat

Personally, I do find it easier to read names like lstatat and statat
with only one extra argument (the file descriptor) than fstatat (...
with 0 or AT_SYMLINK_NOFOLLOW.  With fstatat uses, it seems like I always
have to convert mentally that the presence of AT_SYMLINK_NOFOLLOW means
that a particular use acts like lstat.