Received-SPF: pass (google.com: domain of linux-kernel+bounces-26605-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Mon, 15 Jan 2024 15:41:45 -0800
From: Richard Cochran <richardcochran@gmail.com>
To: Sagi Maimon <maimon.sagi@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>, Andy Lutomirski <luto@kernel.org>,
	tglx@linutronix.de, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Sohil Mehta <sohil.mehta@intel.com>,
	Rick Edgecombe <rick.p.edgecombe@intel.com>,
	Nhat Pham <nphamcs@gmail.com>, Palmer Dabbelt <palmer@sifive.com>,
	Kees Cook <keescook@chromium.org>,
	Alexey Gladkov <legion@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>, linux-kernel@vger.kernel.org,
	linux-api@vger.kernel.org, Linux-Arch <linux-arch@vger.kernel.org>,
	Netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH v3] posix-timers: add multi_clock_gettime system call
Message-ID: <ZaXCuV1Dy0e_E-h0@hoboy.vegasvil.org>
References: <20231228122411.3189-1-maimon.sagi@gmail.com>
 <f254c189-463e-43a3-bc09-9a8869ebf819@app.fastmail.com>
 <CAMuE1bF0Hho4VwO6w3f+9z3j5TtscYzuAjj10MFt2mZXG2P8dQ@mail.gmail.com>
 <84d8e9d7-09ce-4781-8dfa-a74bb0955ae8@app.fastmail.com>
 <ZZ-ZNHgDsZwg9CaW@hoboy.vegasvil.org>
 <CAMuE1bF4sSeiDr-jyebF6F8oRxGs1b2gtT39fTJ2JeaFabr6Ng@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMuE1bF4sSeiDr-jyebF6F8oRxGs1b2gtT39fTJ2JeaFabr6Ng@mail.gmail.com>

On Mon, Jan 15, 2024 at 05:49:32PM +0200, Sagi Maimon wrote:

> Thanks for your notes, all of them will be done on the next patch (it
> will take some time due to work overload).

No hurry, glad you are keeping this going...

> The only question that I have is: why not implement it as an IOCTL?
> It makes more sense to me since it is close to another IOCTL, the
> "PTP_SYS_OFFSET" family.

I've often needed other clock offsets, like CLOCK_REALTIME - CLOCK_MONOTONIC.

Those don't have a character device, and so there is no way to call
ioctl() on them.  That is why I'd like to have a system call that
handles any two clock_t instances, using the most accurate back end
based on the kinds of the two clocks.

Thanks,
Richard