[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 2 Feb 2019 18:15:41 +0100
From: Oliver Hartkopp <socketcan@...tkopp.net>
To: Deepa Dinamani <deepa.kernel@...il.com>, davem@...emloft.net,
linux-kernel@...r.kernel.org
Cc: netdev@...r.kernel.org, arnd@...db.de, y2038@...ts.linaro.org,
ccaulfie@...hat.com, deller@....de, paulus@...ba.org,
ralf@...ux-mips.org, rth@...ddle.net, cluster-devel@...hat.com,
linuxppc-dev@...ts.ozlabs.org, linux-alpha@...r.kernel.org,
linux-arch@...r.kernel.org, linux-mips@...r.kernel.org,
linux-parisc@...r.kernel.org, sparclinux@...r.kernel.org
Subject: Re: [PATCH net-next v5 12/12] sock: Add SO_RCVTIMEO_NEW and
SO_SNDTIMEO_NEW
Hi all,
On 02.02.19 16:34, Deepa Dinamani wrote:
> Add new socket timeout options that are y2038 safe.
(..)
>
> diff --git a/arch/alpha/include/uapi/asm/socket.h b/arch/alpha/include/uapi/asm/socket.h
> index 9826d1db71d0..0d0fddb7e738 100644
> --- a/arch/alpha/include/uapi/asm/socket.h
> +++ b/arch/alpha/include/uapi/asm/socket.h
> @@ -119,19 +119,25 @@
> #define SO_TIMESTAMPNS_NEW 64
> #define SO_TIMESTAMPING_NEW 65
>
> -#if !defined(__KERNEL__)
> +#define SO_RCVTIMEO_NEW 66
> +#define SO_SNDTIMEO_NEW 67
>
> -#define SO_RCVTIMEO SO_RCVTIMEO_OLD
> -#define SO_SNDTIMEO SO_SNDTIMEO_OLD
> +#if !defined(__KERNEL__)
>
> #if __BITS_PER_LONG == 64
> #define SO_TIMESTAMP SO_TIMESTAMP_OLD
> #define SO_TIMESTAMPNS SO_TIMESTAMPNS_OLD
> #define SO_TIMESTAMPING SO_TIMESTAMPING_OLD
> +
> +#define SO_RCVTIMEO SO_RCVTIMEO_OLD
> +#define SO_SNDTIMEO SO_SNDTIMEO_OLD
Maybe I'm a bit late in this discussion as you are already in v5 ...
I can see patches making the transition in different steps where it
might be helpful to name them *_OLD and *_NEW to understand the patches.
But in the end the naming stays in the kernel for a very long time and I
remember myself (in early years) to name things 'new', 'new2', 'new3'.
In fact SO_TIMESTAMP_OLD should be named SO_TIMESTAMP32 and
SO_TIMESTAMP_NEW should be named SO_TIMESTAMP64.
Especially as it tells you what is 'inside', the naming of these new
introduced constants should be replaced with *32 and *64 names.
The documentation and the other comments still fit perfectly then.
Regards,
Oliver
Powered by blists - more mailing lists