On 8/17/15 5:46 AM, Jilles Tjoelker wrote:
On Sun, Aug 16, 2015 at 10:26:21PM +0800, Julian Elischer wrote:
On 8/15/15 1:39 AM, John Baldwin wrote:
On Friday, August 14, 2015 10:46:10 PM Julian Elischer wrote:
I would like to implement this call. but would like input as to it's
The code inside the system would already appear to support handling
three elements, though it needs some scrutiny,
so all that is needed is a system call with the ability to set the
birthtime directly.
Whether it should take the form of the existing calls but expecting
three items is up for discussion.
Maybe teh addition of a flags argument to specify which items are
present and which to set.
I believe these should be new calls.  Only utimensat() provides a flag
argument, but it is reserved for AT_* flags.
Using AT_* flags for things unrelated to pathnames is not without
precedent: AT_REMOVEDIR for unlinkat() and AT_EACCESS for faccessat().
This isn't suitable for a large number of flags, though.

I wasn't suggesting we keep the old ones and silently make them take 3
args :-)
I was thining of suplementing them wth new syscalls and the obvious
names are those you suggested.
however I do wonder if there will ever be a need for a 4th...
This could be indicated by yet another flag.
not in futimens, futimes or any of the other varieties that have no flags..

I'm a bit disappointed that setting birthtimes apparently wasn't needed
when I added futimens and utimensat. However, they are not part of any
release yet, so it may be possible to remove them at some point.
Well they are defined in posix as only taking  the two args right?
I'm not sure I am parsing your statement correctly. It reads a bit like you are
disappointed at yourself, which doesn't seem right.
I think we should keep them as they are part of posix and part of Linux.
We actually independently added them at $JOB (for Linux compat)  but
now we have a need for better birthtime control.
In the meantime UFS2 and ZFS both have birthtime and
its use is getting more widespread.  (not sure if NFSv4 supports it but
Samba needs it for full emulation)
We'd rather add a new call in conjunction with FreeBSD rather than add our own
and see FreeBSD add a slightly different one.

It is possible we could do a syscall capable of doing 3, and just have a library entry
that is compatible with the standard as a front end.

suggestions welcome.

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to