Message-ID: <20240214204254.6208ca2f@meshulam.tesarici.cz>
Date: Wed, 14 Feb 2024 20:42:54 +0100
From: Petr Tesařík <petr@...arici.cz>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Petr Tesarik
 <petrtesarik@...weicloud.com>, Jonathan Corbet <corbet@....net>, David
 Kaplan <david.kaplan@....com>, Larry Dewey <larry.dewey@....com>, Elena
 Reshetova <elena.reshetova@...el.com>, Carlos Bilbao
 <carlos.bilbao@....com>, "Masami Hiramatsu (Google)" <mhiramat@...nel.org>,
 Randy Dunlap <rdunlap@...radead.org>, Petr Mladek <pmladek@...e.com>, "Paul
 E. McKenney" <paulmck@...nel.org>, Eric DeVolder
 <eric.devolder@...cle.com>, Marc Aurèle La France
 <tsi@...oix.net>, "Gustavo A. R. Silva" <gustavoars@...nel.org>, Nhat Pham
 <nphamcs@...il.com>, "Christian Brauner (Microsoft)" <brauner@...nel.org>,
 Douglas Anderson <dianders@...omium.org>, Luis Chamberlain
 <mcgrof@...nel.org>, Guenter Roeck <groeck@...omium.org>, Mike Christie
 <michael.christie@...cle.com>, Kent Overstreet <kent.overstreet@...ux.dev>,
 Maninder Singh <maninder1.s@...sung.com>, "open list:DOCUMENTATION"
 <linux-doc@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>,
 Roberto Sassu <roberto.sassu@...weicloud.com>, Petr Tesarik
 <petr.tesarik1@...wei-partners.com>
Subject: Re: [PATCH v1 5/5] sbm: SandBox Mode documentation

On Wed, 14 Feb 2024 19:48:52 +0100
Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:

> On Wed, Feb 14, 2024 at 05:31:12PM +0100, Petr Tesařík wrote:
> > On Wed, 14 Feb 2024 16:11:05 +0100
> > Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
> >   
> > > On Wed, Feb 14, 2024 at 03:55:24PM +0100, Petr Tesařík wrote:  
> > > > OK, so why didn't I send the whole thing?
> > > > 
> > > > Decomposition of the kernel requires many more changes, e.g. in linker
> > > > scripts. Some of them depend on this patch series. Before I go and
> > > > clean up my code into something that can be submitted, I want to get
> > > > feedback from guys like you, to know if the whole idea would be even
> > > > considered, aka "Fail Fast".    
> > > 
> > > We can't honestly consider this portion without seeing how it would
> > > work, as we don't even see a working implementation that uses it to
> > > verify it at all.
> > > 
> > > The joy of adding new frameworks is that you need a user before anyone
> > > can spend the time to review it, sorry.  
> > 
> > Thank your for a quick assessment. Will it be sufficient if I send some
> > code for illustration (with some quick&dirty hacks to bridge the gaps),
> > or do you need clean and nice kernel code?  
> 
> We need a real user in the kernel, otherwise why would we even consider
> it?  Would you want to review a new subsystem that does nothing and has
> no real users?  If not, why would you want us to?  :)

Greg, please enlighten me on the process. How is something like this
supposed to get in?

Subsystem maintainers will not review code that depends on core features
not yet reviewed by the respective maintainers. If I add only the API
and a stub implementation, then it brings no benefit and attempts to
introduce the API will be dismissed. I would certainly do just that if
I was a maintainer...

I could try to pack everything (base infrastructure, arch
implementations, API users) into one big patch with pretty much
everybody on the Cc list, but how is that ever going to get reviewed?

Should I just go and maintain an out-of-tree repo for a few years,
hoping that it gets merged one day, like bcachefs? Is this the way?

Petr T

Powered by blists - more mailing lists