-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: |>> and both are themselves canned actions. |> There is a set of common canned solutions, such as changing the |> loglevels, adding or removing consoles, increasing the dmesg buffer, |> or overriding init, but there's no telling what happens in the next |> iteration of debugging. |> |> E.g., if some people have problems with the SD driver and you add |> an option to vary the timing, that's probably something you can't |> easily predict. And if your rootfs is on SD, handling this when |> user space is up may not be an option either. | | That's why I think it would be a nice debug feature to have when that | special need comes. The defaults should work for most cases, but when | debugging why limit the developer to only append new settings?
Because it basically ends up same as U-Boot environment... at least by inheriting the commandline from the bootloader we can exercise a light touch in this append file to only set exactly those "debug features" for "special need" that is required, without doing stuff like making the filesystem image itself fragile to whether it runs from NAND or SD, and which partition, etc. I'd like to implement these features now, but it makes sense to take your patches first I think: when are you planning to send them? - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkkZ3SkACgkQOjLpvpq7dMrwdACbBNvw+FbJ9pVyLvGL2xItxXMg sIEAoI/LuVd7bG8DdKoaHCAVkp572X1R =ShUF -----END PGP SIGNATURE-----
