[Elinux-discuss] How to start multi-entity embedded work on specific topics? (boot time, for example)

[Bird, Tim]

> -----Original Message-----
> From: Richard Purdie <richard.purdie at linuxfoundation.org>
> Hi Tim,
> 
> On Fri, 2024-06-07 at 22:52 +0000, Bird, Tim wrote:
> > I'd like to start some collaboration on reducing embedded Linux boot time.
> >
> > The problem is that this work potentially crosses sub-systems, architectures,
> > software project boundaries, build systems, companies, trade associations, etc.
> >
> > I've got an "embedded and IOT" microconference scheduled for Plumbers in Vienna
> > in September.  I'm soliciting topics for boot time reduction, for this micro-conference.
> >
...
> >
> > I'd also possibly like to start some kind of ecosystem-side workgroup on this topic.
> > This is partly inspired by Khasim Syed Mohammed's presentation
> > at last year's Plumbers, were he talked about requirements for automotive boot time and
> > some ideas for specific improvement areas.[1]
> >
> > The LF's embedded Linux Project is no more, so I need a place to organize discussions,
> > and possibly store code in-flight.  I can put some ad-hoc things on the elinux wiki,
> > but is there a better place to do this?  In AGL?, in Linaro?, in CIP?, In Yocto?  At
> > a specific embedded Linux company?  At a processor or product company?
> >
> > Any of these might be a good place to "home" the workgroup.  But there are pros
> > and cons to each location.
> >
> > Let me know what you think.
> 
> FWIW I'd love to see this effort and more like it.
> 
> I'm not sure I can offer development time on it but what I/Yocto
> Project could offer:
> 
> * a place to host the effort/code (git repo, mailing list, wiki etc.)
> * some neutrality to any one company/product
> * an audience that is interested in this kind of work
> * the ability to create a "layer" which showcases the work
> 
> I know you're not a big YP/OE user so I want to explain this last point
> as it is easy to underestimate the power of it.
> 
> The point is to capture in one place the configuration/changes needed
> to make the change in question (fast boot time).
> 
> YP/OE layers are designed to capture and maintain customisation against
> a base OS so they lend themselves well to this task. Even if someone is
> going to optimise something else in the end, seeing all the changes
> documented in the layer format will make it much easier for them to see
> what they need to do.
> 
> I can't speak for the YP advocacy people but I'd imagine they'd be
> interested in helping get a message out about such a project too.

Hi Richard,

Thanks for the response.  This seems like a good place to put things - and I like
the neutrality of it.  I will have to learn some YP myself.  (How did I get this
far in embedded Linux without skills with YP?)  Since I'm not a YP developer,
I would like to do some research to convince myself that a YP layer would
be a good way to deploy this type of technology (kernel configs, in-flight patches,
tools, documentation, etc.), even for those who are not using YP.

Does anyone else want to chime in with any pros and cons with this approach?
For example, could buildroot developers and users utilize information, patches,
tools, etc. stored in YP this way?  Or would this stuff be off their radar?

Thanks very much for the offer.
 -- Tim