Message-ID:
 <MW5PR13MB5632E4EFFD802E0839027A51FD4A2@MW5PR13MB5632.namprd13.prod.outlook.com>
Date: Mon, 28 Oct 2024 01:29:57 +0000
From: "Bird, Tim" <Tim.Bird@...y.com>
To: Saravana Kannan <saravanak@...gle.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



> -----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.    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.
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.
Finally, a lot of this information will be ad hoc, which also doesn't
lend itself to upstreaming.

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?  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.

> - 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