On Wed, 2010-08-04 at 10:09 +0100, Alan Cox wrote:
Fundamentally - no. However the impact it has on a lot of the drivers
will be significant and you'll be submitting a huge patch pile to fix up
all the locking assumptions (for one it means port->tty might change
across any call that ends up in sysrq)
Right. That's nasty. I think we need somewhat to break the loop when
that happens as if we were getting a new interrupt to some extent.
And that's a lot of drivers to fix.
quoted
serial drivers might need to be audited a bit to make sure they cope
with the lock being dropped and re-acquired around the sysrq call.
Architecturally I think it would make more sense to add a new sysrq
helper which merely sets a flag, and check that flag at the end of the IRQ
when dropping the lock anyway.
Interesting idea. That does mean that multiple sysrq in one interrupt
will be coalesced but I don't see that as an issue.
Otherwise it'll be a huge amount of work to even build test all those
consoles.
Right. Better to have a way where we can fix them one at a time. I'll
look into it. Thanks.
Cheers,
Ben.