Re: [PATCH 1/3] Input: sysrq - drop tty argument from sysrq ops handlers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> > 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.


--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux