rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kent Overstreet <kent.overstreet@gmail.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	Chris Suter <chris@sutes.me>,
	Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
	Geert Stappers <stappers@stappers.nl>,
	rust-for-linux <rust-for-linux@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org
Subject: Re: Fwd: Adding crates
Date: Fri, 15 Apr 2022 16:39:26 -0400	[thread overview]
Message-ID: <20220415203926.pvahugtzrg4dbhcc@moria.home.lan> (raw)
In-Reply-To: <df41ae9d0f02953cbfe9491f69247a8035f64562.camel@HansenPartnership.com>

On Fri, Apr 15, 2022 at 09:31:24AM -0400, James Bottomley wrote:
> I think the solution to the problem is to try to maintain highly mobile
> reference implementations and also keep constantly considering what the
> requirements are for mobility (both on the part of the reference
> implementation and the kernel).  I also think that if we ever gave
> impementors the magic ability just to dump any old code in the kernel,
> they'd use it to take the lazy way out because it's a lot easier than
> trying to keep the reference implementation separate.
> 
> The fact that most "reference" implementations don't conform to the
> above isn't something we should be encouraging by supplying
> compatibility APIs that paper over the problem and encourage API bloat.

I think it might help if we had a
 - standard set of review guidelines
 - standard workflow

for pulling in (vendoring, however it gets done) code from external
repositories.

Generally what I see in the community is that people do want to support the
kernel better, but then people see things like Greg's response of "don't do
that" and it turns people off. Instead, we could
 - recognize that it's already being done (e.g. with zstd)
 - put some things in writing about how it _should_ be done

This could help a lot with e.g. the way Facebook maintains ZSTD - if we say
"look, we want this code factored out better so we only have to review the stuff
that's relevant" - the engineers generally won't mind doing that work, and now
they'll have something to take to their managers as justification.

Another thing I'd like to see is more of what the RCU folks have done - liburcu
is _amazing_ in that, at least for me, it's been a drop in replacement for the
kernel RCU implementation - and I would imagine it's as much as possible the
same code. A good candidate would be the kernel workqueue code: workqueues are
_great_ and I don't know of anything like them in userspace. That code should be
seeing wider use! And if it was made an external library that was consumed by
both the kernel and userspace, it could be - but it would require buy in from
kernel people.

But as you were saying about Facebook (and I discovered when I was at Google
many moons ago, as a young engineer) - large organizations tend to be insular,
they like te pretend the outside world doesn't exist. The kernel is one such
organization :) We could be a better citizen by encouraging and enabling efforts
such as this.

  reply	other threads:[~2022-04-15 20:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAKfU0DKvQYjhgiKN83+DZW3CQOkSEdQcy9nXUfFLVn1Uju6GkQ@mail.gmail.com>
2022-03-28  0:41 ` Fwd: Adding crates Chris Suter
2022-03-28  5:41   ` Geert Stappers
2022-03-28 21:38     ` Chris Suter
2022-03-29  5:23       ` Greg KH
2022-03-29  6:02         ` Chris Suter
2022-03-29 15:47           ` Miguel Ojeda
2022-03-30  0:03             ` Chris Suter
2022-03-30  4:31               ` Greg KH
2022-03-30 20:43                 ` Kent Overstreet
2022-04-15 13:31                   ` James Bottomley
2022-04-15 20:39                     ` Kent Overstreet [this message]
2022-04-16  3:27                       ` James Bottomley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220415203926.pvahugtzrg4dbhcc@moria.home.lan \
    --to=kent.overstreet@gmail.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=chris@sutes.me \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=stappers@stappers.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).