From: Jens Axboe <axboe@suse.de>
To: Martin Dalecki <dalecki@evision-ventures.com>
Cc: David Howells <dhowells@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: IDE booting problems with 2.5.23
Date: Thu, 20 Jun 2002 13:05:25 +0200 [thread overview]
Message-ID: <20020620110525.GB812@suse.de> (raw)
In-Reply-To: <3D11B551.9090201@evision-ventures.com>
On Thu, Jun 20 2002, Martin Dalecki wrote:
> >BTW, I see you renamed the flags to channel->active. I think that's a
> >bit misleading, can't you just call it ->state or ->flags (or
> >->state_flags? :-)
>
> My reasoning behind this is - state is for device state
> register and active is well for the state of the driver. All the other
> names seemed for me to be too opaque for the purpose of it or already used.
> flags souns static to me.
> And you have to agree that it is *very* special
> purpose if you look at the IDE_BUSY bit.
> And finally - I took this name from the FreeBSD
> code to make it look a bit more similar.
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
next prev parent reply other threads:[~2002-06-20 11:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-20 9:46 IDE booting problems with 2.5.23 David Howells
2002-06-20 9:56 ` Martin Dalecki
2002-06-20 10:35 ` Jens Axboe
2002-06-20 10:58 ` Martin Dalecki
2002-06-20 11:05 ` Jens Axboe [this message]
2002-06-20 11:22 ` Martin Dalecki
2002-06-20 10:51 ` David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020620110525.GB812@suse.de \
--to=axboe@suse.de \
--cc=dalecki@evision-ventures.com \
--cc=dhowells@redhat.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox