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
>
> 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
--
"H. Peter Anvin" <[email protected]> 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.
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
Jan Engelhardt <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling wrote:
> Jan Engelhardt <[email protected]> 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
>> > 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
--
Jan Engelhardt <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
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
--- "H. Peter Anvin" <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
"H. Peter Anvin" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
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
>> >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/
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
>> > > > 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
--
Jan Engelhardt <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
"H. Peter Anvin" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily