2003-06-27 10:32:11

by Samium Gromoff

[permalink] [raw]
Subject: [BIO] request->flags ambiguity

I might just be completely off base, but something struck me lately as odd, and i`d
like to hear what you folks think about the issue.

I`m wondering about the ambiguity of the struct request->flags field.

Is it ok to have a possibility of a request with conflicting meanings attached to it?
For example REQ_CMD | REQ_PM_SHUTDOWN | REQ_SPECIAL.

It may be, depending on the implementation, that they are not completely
conflicting, but its hard to believe that there is zero ambiguity at all.

If i`m not mistaken this looks as creating opportunities for various subtle bugs.

Shouldn`t it make more sense to separate request-type-indicator flags
into a separate unambiguous type field, which would take
one of the following values:
- read/write request
- sense query
- power control
- special request

And not a currently possible combination of all of them, which seem to be the
current situation.

--
regards, Samium Gromoff


2003-06-27 10:34:18

by Jens Axboe

[permalink] [raw]
Subject: Re: [BIO] request->flags ambiguity

On Fri, Jun 27 2003, Samium Gromoff wrote:
> I might just be completely off base, but something struck me
> lately as odd, and i`d like to hear what you folks think about
> the issue.
>
> I`m wondering about the ambiguity of the struct request->flags
> field.
>
> Is it ok to have a possibility of a request with conflicting
> meanings attached to it? For example REQ_CMD | REQ_PM_SHUTDOWN
> | REQ_SPECIAL.

No of course not.

> It may be, depending on the implementation, that they are not
> completely conflicting, but its hard to believe that there is
> zero ambiguity at all.
>
> If i`m not mistaken this looks as creating opportunities for
> various subtle bugs.
>
> Shouldn`t it make more sense to separate request-type-indicator
> flags into a separate unambiguous type field, which would take
> one of the following values: - read/write request - sense query
> - power control - special request
>
> And not a currently possible combination of all of them, which
> seem to be the current situation.

There has been talk of that before, search the archives.

--
Jens Axboe

2003-06-27 11:15:09

by Jens Axboe

[permalink] [raw]
Subject: Re: [BIO] request->flags ambiguity

On Fri, Jun 27 2003, Samium Gromoff wrote:
> On Fri, 27 Jun 2003 12:48:22 +0200
> Jens Axboe <[email protected]> wrote:
> -- snip --
> > > Is it ok to have a possibility of a request with conflicting
> > > meanings attached to it? For example REQ_CMD | REQ_PM_SHUTDOWN
> > > | REQ_SPECIAL.
> >
> > No of course not.
> -- snip --
> > > Shouldn`t it make more sense to separate request-type-indicator
> > > flags into a separate unambiguous type field, which would take
> > > one of the following values: - read/write request - sense query
> > > - power control - special request
> > >
> > > And not a currently possible combination of all of them, which
> > > seem to be the current situation.
> >
> > There has been talk of that before, search the archives.
>
> Umm, i`ve tried and failed, couldn`t you share some vague
> pointers about the topic or something?

Some pointers here

http://marc.theaimsgroup.com/?l=linux-kernel&m=105482104321668&w=2

--
Jens Axboe

2003-06-27 11:12:25

by Samium Gromoff

[permalink] [raw]
Subject: Re: [BIO] request->flags ambiguity

On Fri, 27 Jun 2003 12:48:22 +0200
Jens Axboe <[email protected]> wrote:
-- snip --
> > Is it ok to have a possibility of a request with conflicting
> > meanings attached to it? For example REQ_CMD | REQ_PM_SHUTDOWN
> > | REQ_SPECIAL.
>
> No of course not.
-- snip --
> > Shouldn`t it make more sense to separate request-type-indicator
> > flags into a separate unambiguous type field, which would take
> > one of the following values: - read/write request - sense query
> > - power control - special request
> >
> > And not a currently possible combination of all of them, which
> > seem to be the current situation.
>
> There has been talk of that before, search the archives.

Umm, i`ve tried and failed, couldn`t you share some vague pointers about the topic
or something?

I`m sorry, but my curiosity prevailed over hesitation to bother you :-)
>
> --
> Jens Axboe
>
>
--
regards, Samium Gromoff


--