> What if the xstat() and struct xstat eventually becomes what userspace
> uses as stat() (as a wrapper) and struct stat (if such a thing is
> possible with glibc versioning)?
It's certainly possible with symbol versioning, though it seems much more
likely that we'd stick with the existing struc
> fileinfoat() perhaps? I think stat*at() is better, though, as people are
> used to the stat function family.
Names like that were all I had thought of when I said I hadn't thought of
any good ones. ;-)
> I've no particular attachment to the name 'xstat'. If you'd prefer 'statx' I
> could go for that.
I prefer something other than xstat and statx(at) seems acceptable enough.
What I'd really prefer is a name that is less meaninglessly arcane,
but I haven't thought of any good ones.
Thanks,
Rola
> Interesting. I wasn't intending to provide both statx() and statxat()
> variants, just the latter, in which case I'd've though that -at suffix is
> redundant.
It's certainly fine to provide only *at flavors for any new syscall, IMHO.
The * case is always just a simple degenerate case of *at, an
> Roland McGrath wrote:
>
> > statx seems like a better family of names. I also think it's worthwhile to
> > see if the interface can be made to more closely match the AIX precedent.
>
> I'm not sure we can make Linux xstat (or whatever) match AIX statxat
statx seems like a better family of names. I also think it's worthwhile to
see if the interface can be made to more closely match the AIX precedent.
Thanks,
Roland
I have no comment on the functionality. But "xstat" is probably a poor
choice of name. There is precedent for that function name with different
meaning in the userland APIs. (It's a moderately useless meaning inherited
from SVR4, but regardless overloading a name previously used is unwise.)
Th
> I'm getting the feeling that the question of whether to step into
> signal handlers is orthogonal to single-stepping;
No, it's not. You only ever step into a handler when you ask to.
That's already the interface.
> Platforms which don't implement PTRACE_SINGLESTEP would probably
> appreciate
