On Tue, Jun 04, 2013 at 11:58:12AM +0200, Hans de Goede wrote:
> Hi,
>
> On 06/03/2013 10:25 PM, Michael Roth wrote:
>
>
>
> >To fix these, let's just drop the BH.
> >
> >Since the initial reasoning for using it still applies to an extent,
> >work around that by deferring the delivery of CHR_EV
Hi,
On 06/03/2013 10:25 PM, Michael Roth wrote:
To fix these, let's just drop the BH.
Since the initial reasoning for using it still applies to an extent,
work around that by deferring the delivery of CHR_EVENT_OPENED until
after the chardevs have been fully initialized, toward the end of
qm
Michael Roth writes:
> When CHR_EVENT_OPENED was initially added, it was CHR_EVENT_RESET,
> and it was issued as a bottom-half:
>
> 86e94dea5b740dad65446c857f6959eae43e0ba6
>
> Which we basically used to print out a greeting/prompt for the
> monitor.
>
> AFAICT the only reason this was ever done
When CHR_EVENT_OPENED was initially added, it was CHR_EVENT_RESET,
and it was issued as a bottom-half:
86e94dea5b740dad65446c857f6959eae43e0ba6
Which we basically used to print out a greeting/prompt for the
monitor.
AFAICT the only reason this was ever done in a BH was because in
some cases we'd
