Message-ID: <CAGETcx-Y6LHpZZUeexeuSF4RJ1E2MDtNtST=ytEUPAj7kKzwFA@mail.gmail.com>
Date: Mon, 28 Oct 2024 15:33:29 -0700
From: Saravana Kannan <saravanak@...gle.com>
To: "Bird, Tim" <Tim.Bird@...y.com>
Cc: "linux-embedded@...r.kernel.org" <linux-embedded@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Boot-time initiative (SIG) thoughts and next steps

On Sun, Oct 27, 2024 at 6:30 PM Bird, Tim <Tim.Bird@...y.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Saravana Kannan <saravanak@...gle.com>
> > On Fri, Oct 25, 2024 at 11:18 AM Bird, Tim <Tim.Bird@...y.com> wrote:
> > >
> > > Hey Linux developers,
> > >
> > > The response to my request to form a Special Interest Group for boot-time reduction
> > > for Linux has been really great.  Many people contacted me by e-mail and on LinkedIn.
> >
> > Hi Tim,
> >
> > Thanks for organizing this and moving it forward! I'd be interested in
> > contributing to this effort as a lot of work I have done aligns with
> > the goals of this effort and boot time is of obvious value to Android.
>
> Thanks for your interest.  I would love to have developers from Google,
> and from the Android community, involved.
>
> >
> > > I had hoped to push out a script today to start to gather data on boot-time on different
> > > platforms, for people to run who had expressed interest in helping with this effort. But
> > > I got overwhelmed with other tasks, and I may not get it done today.  I'll be in Tokyo next
> > > week for Open Source Summit Japan.  If you are there, please try to catch me and say hi.
> > > Given that, I'll see how soon I can provide the script I'm talking about, and we can
> > > discuss the goals and design of the script.
> > >
> > > A couple of quick things:
> > > There are lots of things to discuss, but here are a few things to get started with...
> > >
> > > = wiki account =
> > > The wiki where we'll be maintaining information about
> > > boot time, and about activities of the boot time SIG, is the elinux wiki.
> > > The page we'll be focusing on is: https://elinux.org/Boot_Time.
> > > If you are interested in helping update and maintain the information there
> > > (which I hope almost everyone is), then please make sure you have a user
> > > account on the wiki.
> > > If you don't have one, please go here:
> > > https://elinux.org/Special:RequestAccount
> > > I have to manually approve accounts in order to fight spambots.  It might
> > > take a few days for me to get to your request.  It's very helpful if you
> > > put a comment in one of the request fields about this being related to
> > > the boot-time initiative or SIG, so I can distinguish your request from
> > > spam requests.
> >
> > Can we instead keep this all a part of the kernel docs instead of the
> > wiki? Couple of reasons for that:
>
> Ideally, we would put some material in the wiki, and also
> produce a document - some kind of "boot-time tuning guide" that can
> live in the kernel tree.

This is the part I care most about being in the kernel docs. Eg: what
configs to use. What commandline params to set. Dos and Don'ts for the
drivers, etc. So, good to see that is an acceptable option.

> Some of the material that I think we will
> maintain will refer to boot sequences and operations outside the
> kernel (such as the bootloader or user-space), so the scope of
> the material to document is not just limited to the kernel.

Makes sense.

> Also, there will be a lot of material that will be system-specific.
> Historically, the kernel has avoided documenting things that are
> specific to an individual platform.

A lot of kernel params are arch specific and we still document them in
the kernel. So I don't there's some leeway. But yeah, doesn't make
sense to document stuff like "improve RPi 4 boot time" kinds of stuff
in the kernel. But not sure that makes sense for the elinux.org wiki
either. But we can figure this out as we go.

> Finally, a lot of this information will be ad hoc, which also doesn't
> lend itself to upstreaming.

At least for the kernel params and configs, I don't think it's that
adhoc. The rest, I don't have an opinion.

> See my response to your individual points below.
>
> > - Since the instructions can be kernel version specific (as things
> > change), it makes sense to have the document synced with the kernel.
>
> That's a good point.  The current material suffers from not being synced
> very well with kernel versions.  That is, there is a lot of obsolete material.
> My own experience is that kernel documentation also has a bit of an issue
> with being kept up-to-date, but it's not as bad as wikis often get.
>
> It would be good to have some plans and possibly mechanisms to address
> the eventual obsolescence of the material.
>
> > - It's one less account to maintain and less chores for you.
> The cost per developer is one-time, which shouldn't be too bad
> for individual developers.  I already have the role of elinux administrator,
> and so I have to approve accounts anyway.  In either case
> (contributing to a wiki or contributing upstream), there is going to
> be some overhead for reviewing the material.
>
> > - One less business approval to get in terms of contributing to
> > external sources.
> This is an interesting point.  Does Google have rules regarding contributing
> to wikis?

In all the companies I've worked at, there's always been some level of
sanity check about external contributions to make sure you aren't
accidentally/intentionally signing up the company for something the
company doesn't agree with.

The point is that I don't know what Google's position is wrt
elinux.org and I need to find it out and/or go through any paperwork
that might be necessary to get approval. All that adds a lot of
inertia, at least for me. I know we are okay contributing to LMKL, so
that makes kernel docs a frictionless process from an approval
perspective. And with the other points in mind about bit rot and
keeping things in sync with kernel, I'd prefer the kernel parts of it
being in the kernel docs.

> That is actually related to my plans to use automation to collect
> boot-time data.  My plan is to have tests that automatically send data
> to a central collection server (with data that is put into a shared, public database).
> I realize there will be some companies who won't want to share certain
> details of their in-development platforms.  When I publish the first
> script that does that (probably this week or next), we should discuss the
> ramifications of developers needing company consent for this.

My comment wasn't about this part at all. I don't think boot timing
needs to be run on any unreleased device. There are plenty of released
devices to test with. And we are actively adding Pixel 6 support to
upstream.

-Saravana

> > - Less chance of bit rot. As people make changes, the docs are right
> > there to go fix.
> You are right that bit rot is a significant risk with wikis, because there are
> no mechanisms to automatically update or remove obsolete material.
> I have some plans to fix that with some test instrumentation and upstream
> wiki processes that can automatically detect changes to published data,
> and can recommend review of material, or flag it as obsolete.
>
> My own experience is that it is significantly easier to change
> something on a wiki, than it is to change upstream kernel documentation.
> One requires just changing text using a web form, and the other requires
> an upstream-compatible e-mail based submit/review/approve/release cycle.
>
> I'm interested to learn more about the barriers that developers at Google (or other
> companies) might face in making contributions to a wiki.  Can you describe
> those obstacles in more detail?
>
> Thanks,
>  -- Tim
>
>
>

Powered by blists - more mailing lists