[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201011080756.50930.arnd@arndb.de>
Date: Mon, 8 Nov 2010 07:56:50 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Richard Cochran <richardcochran@...il.com>
Cc: linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Christoph Lameter <cl@...ux.com>,
John Stultz <johnstul@...ibm.com>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH RFC 2/8] clock device: convert clock_gettime
On Thursday 04 November 2010, Richard Cochran wrote:
> diff --git a/include/linux/posix-timers.h b/include/linux/posix-timers.h
> index 3e23844..70f40e6 100644
> --- a/include/linux/posix-timers.h
> +++ b/include/linux/posix-timers.h
> @@ -17,10 +17,22 @@ struct cpu_timer_list {
> int firing;
> };
>
> +/* Bit fields within a clockid:
> + *
> + * The most significant 29 bits hold either a pid or a file descriptor.
> + *
> + * Bit 2 indicates whether a cpu clock refers to a thread or a process.
> + *
> + * Bits 1 and 0 give the type: PROF=0, VIRT=1, SCHED=2, or FD=3.
> + *
> + * A clockid is invalid if bits 2, 1, and 0 all set (see also CLOCK_INVALID
> + * in include/linux/time.h)
> + */
> +
> #define (clock) ((pid_t) ~((clock) >> 3))
> #define CPUCLOCK_PERTHREAD(clock) \
> (((clock) & (clockid_t) CPUCLOCK_PERTHREAD_MASK) != 0)
> -#define CPUCLOCK_PID_MASK 7
> +
> #define CPUCLOCK_PERTHREAD_MASK 4
> #define CPUCLOCK_WHICH(clock) ((clock) & (clockid_t) CPUCLOCK_CLOCK_MASK)
> #define CPUCLOCK_CLOCK_MASK 3
> @@ -28,12 +40,17 @@ struct cpu_timer_list {
> #define CPUCLOCK_VIRT 1
> #define CPUCLOCK_SCHED 2
> #define CPUCLOCK_MAX 3
> +#define CLOCKFD CPUCLOCK_MAX
> +#define CLOCKFD_MASK (CPUCLOCK_PERTHREAD_MASK|CPUCLOCK_CLOCK_MASK)
It looks like you are turning a kernel internal interface into a user ABI,
which I think is highly questionable. Using the bits like this internally is
ok, but making it part of the syscall ABI means that we can never change this
in the future.
Maybe I was misunderstanding your patch though.
Arnd
--
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