Andy Green wrote: > This is like the third time I ask for that killer scenario where we need > a change in kernel parameters for normal use
I already gave you one, the kernel log buffer. That's a pretty common small adjustment that you may also ask users to make to catch the full story of an intermittent crash they're seeing. Another example would be transition of something like the ECC algorithm: 1) you implement the new algorithm, add a switch, but leave the old one as default 2) developers can now test it in their normal environment 3) if it's good, you recommend switching to the new algorithm 4) people migrate their system at their convenience. When they change the algorithm has no impact on whether they have access to other new kernel features or fixes. 5) at some point in time, you change the default 6) even later, you throw out the old functionality and remove the option (which is then just ignored) Yet another example would be drivers that need some early or static configuration. E.g., some USB drivers need to be told about IDs. For instance, you need to pass those parameters to the FTDI driver to use our debug board. In all these cases, you could avoid using a boot parameter. But it's a standard feature in the Linux kernel that has been around for some 16 years, so both users and developers will expect it to be available, and you can't count on not eventually running into a situation where things get painful if it's not readily available. Besides, what would be the gain of getting rid of it ? Then you'd just force people to make that configuration change by some other means, and then you'd have to figure out where else that dreaded persistent state is hidden. > that can't be handled in Qi update. But you don't want to have to update qi. Eventually, we want to treat it like NOR, i.e., not even advanced users should have to update it. That way, it can always be relied upon to boot the system. > Can you provide a link to where I made that "clear"? Should be easy > since you state it as a fact. Heh, I think I can tell by now when we reach the point in a discussion where you dig in and will defend that position to the knife ;-) > ~ And it is clear we should implement a full backup rootfs re-using > normal packages since we have all the bits and bobs to hand. Hmm, depends on what you mean by "full". I don't think we really want to have much of our GUI there, and probably most of the services won't be terribly useful either. It's not a question of space or whether we can do it, but just of keeping things reasonably simple and avoiding to have to deal with bugs in exotic subsystems. (E.g., if you include GPS in the boot loader, and it has problems, I think you have to be incredibly bored to want to debug that ;-) If you mean "shell and the usual utilities", then I'd agree that we shouldn't be too stingy, since they're likely to be very well tested and have reasonably low complexity. I'd even throw in a very simple GUI, like the Petitboot we've already talked about. - Werner
