[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101112105358.GA20425@riccoc20.at.omicron.at>
Date: Fri, 12 Nov 2010 11:53:58 +0100
From: Richard Cochran <richardcochran@...il.com>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Kyle Moffett <kyle@...fetthome.net>,
Thomas Gleixner <tglx@...utronix.de>,
Alexander Shishkin <virtuoso@...nd.org>,
Valdis.Kletnieks@...edu, linux-kernel@...r.kernel.org,
John Stultz <johnstul@...ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
"H. Peter Anvin" <hpa@...or.com>,
Kay Sievers <kay.sievers@...y.org>, Greg KH <gregkh@...e.de>,
Chris Friesen <chris.friesen@...band.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"Kirill A. Shutemov" <kirill@...temov.name>
Subject: Re: [PATCHv6 0/7] system time changes notification
On Fri, Nov 12, 2010 at 09:25:04AM +0000, Alan Cox wrote:
> > #define CLOCK_FD 0x80000000
> > fd = open("/dev/clock/realtime", O_RDWR);
> > poll(fd);
> > clock_gettime(CLOCK_FD|fd, &ts);
> > [...]
>
> Oh please. Can we not manage to vaguely follow the direction of other
> syscalls and instead of magic flag hacks just add
>
> fclock_gettime
Did you see my recent post on dynamic clock ids, from Nov 4th?
It implements the clock lifetime cycle, and I would like to here your
comments on that.
I did not implement the clock_* syscalls in new forms as fclock_* but
will do so if there is agreement about it.
IMHO, from the application point of view, it would be nicer to be able
to mix and match dynamic clock ids with the CLOCK_ ids using a
clockid_t and the existing posix clock_* calls.
Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists