[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87v81txjb7.ffs@tglx>
Date: Fri, 28 Jun 2024 15:56:12 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: "Jason A. Donenfeld" <Jason@...c4.com>, Aleksa Sarai <cyphar@...har.com>
Cc: linux-kernel@...r.kernel.org, patches@...ts.linux.dev,
linux-crypto@...r.kernel.org, linux-api@...r.kernel.org, x86@...nel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Adhemerval Zanella Netto
<adhemerval.zanella@...aro.org>, Carlos O'Donell <carlos@...hat.com>,
Florian Weimer <fweimer@...hat.com>, Arnd Bergmann <arnd@...db.de>, Jann
Horn <jannh@...gle.com>, Christian Brauner <brauner@...nel.org>, David
Hildenbrand <dhildenb@...hat.com>
Subject: Re: [PATCH v18 2/5] random: add vgetrandom_alloc() syscall
Jason!
On Thu, Jun 20 2024 at 14:18, Jason A. Donenfeld wrote:
> On Wed, Jun 19, 2024 at 07:13:26PM -0700, Aleksa Sarai wrote:
>> Then again, I guess since libc is planned to be the primary user,
>> creating a new syscall in a decade if necessary is probably not that big
>> of an issue.
>
> I'm not sure going the whole big struct thing is really necessary, and
> for an additional reason: this is only meant to be used with the vDSO
> function, which is also coupled with the kernel. It doesn't return
> information that's made to be used (or allowed to be used) anywhere
> else. So both the vdso code and the syscall code are part of the same
> basic thing that will evolve together. So I'm not convinced extensible
> struct really makes sense for this, as neat as it is.
>
> If there's wide consensus that it's desirable, in contrast to what I'm
> saying, I'm not vehemently opposed to it and could do it, but it just
> seems like massive overkill and not at all necessary. Things are
> intentionally as simple and straightforward as can be.
Right, but the problem is that this is a syscall, so people are free to
explore it even without the vdso part. Now when you want to change it
later then you are caught in the no-regression trap.
So making it extensible with backwards compability in place (add the
unused flag field and check for 0) will allow you to expand without
breaking users.
Thanks,
tglx
Powered by blists - more mailing lists