How about busy_flags or busy_state, then? Active sounds like a bool to
me, and frankly what FreeBSD uses really has no bearing on what we
should choose :-)
> Another tought:
>
> - We will have then an IDE_DMA which will indicate clearly
> that we are expecting some async event for the sake of DMA.
Right
> But we have IDE_BUSY overloaded with both:
>
> - Flagging that we are expecting an IRQ to arrive during
> PIO io (in conjencture with ->handler != NULL).
>
> - Flagging that the do_request code path should be reentered
> immediately or is busy.
>
> I thihink its hard but worth it to split the semantic overload.
> In esp. a very fragile change. But I *feel* like it would
> be worth it. Suggestions opinnions?
Keep IDE_BUSY as saying 'we are busy handling an event', ie expecting an
interrupt at some point. This is what is serializing access to the
channel, not the spin lock btw. Only one 'user' can flag the channel as
busy and then proceed to setup a command etc.
I dunno about your #2, that sounds a bit confusing.
-- Jens Axboe- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/