[BIO] request->flags ambiguity

[BIO] request->flags ambiguity

[Samium Gromoff]

	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

Re: [BIO] request->flags ambiguity

[Samium Gromoff]

On Fri, 27 Jun 2003 12:48:22 +0200
Jens Axboe <axboe@suse.de> 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


-- 

Re: [BIO] request->flags ambiguity

[Jens Axboe]

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

Re: [BIO] request->flags ambiguity

[Jens Axboe]

On Fri, Jun 27 2003, Samium Gromoff wrote:
> On Fri, 27 Jun 2003 12:48:22 +0200
> Jens Axboe <axboe@suse.de> 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