On Sunday, August 16, 2015 12:05:07 PM Adrian Chadd wrote: > .. then make it take a struct and a type flag. :P > > Then you can extend it however you'd like. I think that might be a bit much (making it a struct), but one option could be to add an argument that says how many timespecs are in the array. Any "missing" timespecs could be treated as if they were set to UTIME_OMIT. This would in theory mean you could support additional timestamps in the future without needing new calls. I'm just not sure if there are any conceivable timestamps such that this flexibility is warranted? > -adrian > > On 16 August 2015 at 07:26, Julian Elischer <julian_at_freebsd.org> 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 > >>> nature. > >>> 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. > >>> > >>> ideas? > >> > >> I believe these should be new calls. Only utimensat() provides a flag > >> argument, but it is reserved for AT_* flags. > > > > 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... > > > >> I would be fine with > >> something like futimens3() and utimensat3() (where 3 means "three > >> timespecs"). Jilles implemented futimens() and utimensat(), so he > >> might have ideas as well. I would probably stick the birth time in > >> the third (final) timespec slot to make it easier to update new code > >> (you can use an #ifdef just around ts[2] without having to #ifdef the > >> entire block). > >> > > > > _______________________________________________ > > freebsd-current_at_freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" -- John BaldwinReceived on Mon Aug 17 2015 - 20:29:55 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:59 UTC