From Tim.Bird at sony.com Mon Jun 10 21:33:04 2024 From: Tim.Bird at sony.com (Bird, Tim) Date: Mon, 10 Jun 2024 21:33:04 +0000 Subject: [Elinux-discuss] How to start multi-entity embedded work on specific topics? (boot time, for example) In-Reply-To: <997dee7b5419e2e1129dbfbbfa91564a709d7c79.camel@linuxfoundation.org> References: <997dee7b5419e2e1129dbfbbfa91564a709d7c79.camel@linuxfoundation.org> Message-ID: > -----Original Message----- > From: 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. > > ... > > > > 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 From r.schwebel at pengutronix.de Tue Jun 11 05:43:30 2024 From: r.schwebel at pengutronix.de (Robert Schwebel) Date: Tue, 11 Jun 2024 07:43:30 +0200 Subject: [Elinux-discuss] How to start multi-entity embedded work on specific topics? (boot time, for example) In-Reply-To: References: <997dee7b5419e2e1129dbfbbfa91564a709d7c79.camel@linuxfoundation.org> Message-ID: On Mon, Jun 10, 2024 at 09:33:04PM +0000, Bird, Tim wrote: > 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? Taken the fact that yocto is the de-facto standard build system for many projects these days, I would say a yocto layer is a valid option for storing this kind of information. At Pengutronix, most of our projects are based on yocto, ptxdist and some variant of debian these days (in this order). If the information is not burried deeply in some yocto magic, it's usually easy to extract it for the other build systems if necessary. The bigger challenge will be to convince the respective upstream projects that boot time optimization is a value and not traded against developer convenience. IMHO, boot time optimization methods will only have a chance if they are easy to use. You can always optimize a system in a pathologic way, so it is fast but not easy-to-update any more. Which is much more of a value in times where the kernel folks create 10 CVEs every day while manufacturers are challenged with regulations (i.e the EU cyber resilience act). rsc -- Pengutronix e.K. | Dipl.-Ing. Robert Schwebel | Steuerwalder Str. 21 | https://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 | From Tim.Bird at sony.com Wed Jun 12 20:52:47 2024 From: Tim.Bird at sony.com (Bird, Tim) Date: Wed, 12 Jun 2024 20:52:47 +0000 Subject: [Elinux-discuss] How to start multi-entity embedded work on specific topics? (boot time, for example) In-Reply-To: References: <997dee7b5419e2e1129dbfbbfa91564a709d7c79.camel@linuxfoundation.org> Message-ID: > -----Original Message----- > From: Robert Schwebel > On Mon, Jun 10, 2024 at 09:33:04PM +0000, Bird, Tim wrote: > > 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? > > Taken the fact that yocto is the de-facto standard build system for many > projects these days, I would say a yocto layer is a valid option for > storing this kind of information. > > At Pengutronix, most of our projects are based on yocto, ptxdist and > some variant of debian these days (in this order). If the information is > not burried deeply in some yocto magic, it's usually easy to extract it > for the other build systems if necessary. Thanks. This is very useful feedback. > > The bigger challenge will be to convince the respective upstream > projects that boot time optimization is a value and not traded against > developer convenience. IMHO, boot time optimization methods will only > have a chance if they are easy to use. You can always optimize a system > in a pathologic way, so it is fast but not easy-to-update any more. Yes. It's sometimes challenging to get boot time reductions upstream, because you end up specializing the boot process for a particular board, use case, or market. It is best to try to find technologies that can be easily utilized by developers working on boot time reduction, and get the technologies upstream. It's even better if you can provide some tools to automate customizations of the system. For example, it would be nice to have a tool that took a snapshot of the device nodes to define them statically, in order to avoid probing and adding always-present ones during system initialization. Also nice would be a tool to identify device drivers which could be loaded later in the initialization sequence, and marking them for deferred loading. Thanks again for the response. It should be a good discussion at Plumbers. -- Tim From wminer at linuxfoundation.org Wed Jun 12 21:42:59 2024 From: wminer at linuxfoundation.org (Walt Miner) Date: Wed, 12 Jun 2024 17:42:59 -0400 Subject: [Elinux-discuss] How to start multi-entity embedded work on specific topics? (boot time, for example) In-Reply-To: References: <997dee7b5419e2e1129dbfbbfa91564a709d7c79.camel@linuxfoundation.org> Message-ID: Walt Miner AGL Community Manager The Linux Foundation Visit us at: www.automotivegradelinux.org lists.automotivelinux.org www.linuxfoundation.org On Wed, Jun 12, 2024 at 4:53?PM Bird, Tim wrote: > > > > -----Original Message----- > > From: Robert Schwebel > > On Mon, Jun 10, 2024 at 09:33:04PM +0000, Bird, Tim wrote: > > > 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? > > > > Taken the fact that yocto is the de-facto standard build system for many > > projects these days, I would say a yocto layer is a valid option for > > storing this kind of information. > > > > At Pengutronix, most of our projects are based on yocto, ptxdist and > > some variant of debian these days (in this order). If the information is > > not burried deeply in some yocto magic, it's usually easy to extract it > > for the other build systems if necessary. > > Thanks. This is very useful feedback. > > > > > The bigger challenge will be to convince the respective upstream > > projects that boot time optimization is a value and not traded against > > developer convenience. IMHO, boot time optimization methods will only > > have a chance if they are easy to use. You can always optimize a system > > in a pathologic way, so it is fast but not easy-to-update any more. > > Yes. It's sometimes challenging to get boot time reductions upstream, > because you end up specializing the boot process for a particular board, > use case, or market. This has been the case for AGL and automotive in general. Boot time optimizations are not applicable to the specialized boards and use cases. We gave up on boot time work in favor of other things quite a while ago. Walt > It is best to try to find technologies that can > be easily utilized by developers working on boot time reduction, and > get the technologies upstream. It's even better if you can provide some > tools to automate customizations of the system. For example, it would > be nice to have a tool that took a snapshot of the device nodes to define > them statically, in order to avoid probing and adding always-present ones > during system initialization. Also nice would be a tool to identify device > drivers which could be loaded later in the initialization sequence, and > marking > them for deferred loading. > > Thanks again for the response. It should be a good discussion at Plumbers. > -- Tim > > _______________________________________________ > Elinux-discuss mailing list > Elinux-discuss at lists.elinux.org > http://lists.elinux.org/mailman/listinfo/elinux-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: