| > Did you file a bug with your system's firmware provider or with upstream? Nope, I patched my code to mainline the bits directly to where they were going. > ...it's how OpenBMC provides the console via IPMI, Redfish, SSH... Which is why I didn't bother with upstreaming :) I'm all for it generally, but in this specific case I saved myself and others time (distilling a reproducible test case, crafting code for public consumption, arguing my case, etc); I'm not the target market - I'd cut the BMC traces if I could without wrecking the machine. > ...was pretty important for getting the project off the ground. Sure, but far too close to the metal for my liking. But then I've always bristled at the sight of it being used to replace far more constrained tools - where constraint is desirable (like build systems). > There's some nuance to this... That was mercifully high-level, but touches on an major concern of mine that is more to do with Aspeed than OpenBMC: backdoored blobs. The AST2500 is constantly sniffing a software defined uart for a magic sequence to drop it into the debug shell... this is the opposite of what I'm looking for in a secure or performant system. > I agree it can be difficult to debug where things are going wrong in the console pipeline. Yup, without even considering the client hardware/OS/application stack, or the getty process on the host you actually want to talk to. I've actually been researching a bug that made it into BSD4, the fountain head. Nobody seems to have noticed that a bunch of terminal attributes, when set from gettytab, stopped having any effect 30 years ago (aside from a single potentially related unanswered complaint on Usenet in 91). http://students.engr.scu.edu/~sschaeck/misc/aspeed-edac.html |