> -----Original Message----- > From: Saravana Kannan <saravanak@xxxxxxxxxx> > On Fri, Oct 25, 2024 at 11:18 AM Bird, Tim <Tim.Bird@xxxxxxxx> 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
