[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100804100926.3f24f5e5@lxorguk.ukuu.org.uk>
Date: Wed, 4 Aug 2010 10:09:26 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>,
linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
David Airlie <airlied@...ux.ie>,
David Miller <davem@...emloft.net>,
Fenghua Yu <fenghua.yu@...el.com>,
Greg Kroah-Hartman <gregkh@...e.de>,
Jason Wessel <jason.wessel@...driver.com>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
Russell King <linux@....linux.org.uk>,
Tony Luck <tony.luck@...el.com>
Subject: Re: [PATCH 1/3] Input: sysrq - drop tty argument from sysrq ops
handlers
> I have a patch to drop the lock in serial_core.h, I'll post that
> tomorrow hopefully, just checking if there's any objection there ? The
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)
> 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.
Otherwise it'll be a huge amount of work to even build test all those
consoles.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists