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

[Richard Purdie]

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.
> 
> What is the best way to do outreach for this?
> I know of a few people I'll be contacting directly to see if they want to repeat
> material I've seen from them in the past.  But I'd like to make sure other
> people know about the session.  Any suggestions for people I should contact,
> or groups, companies or lists that I should announce this on (besides linkedin
> and this list)?
> 
> 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.

Cheers,

Richard