Add scsi_execute_async_fifo()

NACK.

First scsi_execute_async has a horrible API and thus it's on it's way out, no way we'll add another variant of it.

Second we're not going to add things to the core just for out of tree modules.

Regarding out-of-tree modules: this is just a preparatory step before submitting SCST for inclusion in the mainstream kernel.

Regarding scsi_execute_async(): I didn't know that this API is on its way out. What will it be replaced by, and when ?

Bart.

Quoted 2 lines · Bart Van Assche

Regarding out-of-tree modules: this is just a preparatory step before submitting SCST for inclusion in the mainstream kernel.

And what crackpipe did you smoke to thing we'd put duplicated target framework in?

James Bottomley clearly expressed in that thread that he doesn't want to maintain two SCSI target frameworks. So what I propose is that SCST is included in the mainline and afterwards that it is evaluated whether or not it is desirable to keep other target code in the mainline kernel.

Quoted 5 lines · Bart Van Assche

James Bottomley clearly expressed in that thread that he doesn't want to maintain two SCSI target frameworks. So what I propose is that SCST is included in the mainline and afterwards that it is evaluated whether or not it is desirable to keep other target code in the mainline kernel.

That's not the way it works, sorry.

The way to get SCST in is to work with the people who care about target frameworks (which doesn't include me, fwiw). You come to a consensus about the way to proceed. Normally this will be a gradual migration of the good bits from SCST into the kernel. In *exceptional* circumstances, we've replaced one piece of infrastructure with another (eg wireless midlayers), but those are by no means the preferred ways to go.

Let me just re-emphasise this bit. You HAVE to work with the existing people. If you can't come to a common understanding, your code won't get in. Even if it's better.

Quoted 16 lines · Matthew Wilcox

Quoted 5 lines · Bart Van Assche

James Bottomley clearly expressed in that thread that he doesn't want to maintain two SCSI target frameworks. So what I propose is that SCST is included in the mainline and afterwards that it is evaluated whether or not it is desirable to keep other target code in the mainline kernel.

That's not the way it works, sorry.

The way to get SCST in is to work with the people who care about target frameworks (which doesn't include me, fwiw). You come to a consensus about the way to proceed. Normally this will be a gradual migration of the good bits from SCST into the kernel. In *exceptional* circumstances, we've replaced one piece of infrastructure with another (eg wireless midlayers), but those are by no means the preferred ways to go.

Quoted 3 lines

Let me just re-emphasise this bit. You HAVE to work with the existing people. If you can't come to a common understanding, your code won't get in. Even if it's better.

Which target code is already in the mainline kernel, and who are the maintainers for this code ? I checked the MAINTAINERS file in the 2.6.25 tarball, but in this file I could not find the information I was looking for.

Um, you claimed to be running benchmarks against it in the thread you just quoted to push for SCST inclusion. If you genuinely don't know which code is actually in the kernel, what exactly were the benchmarks against?

Which target code is already in the mainline kernel, and who are the maintainers for this code ? I checked the MAINTAINERS file in the 2.6.25 tarball, but in this file I could not find the information I was looking for.

Can you really not locate drivers/scsi/scsi_tgt_lib.c in the tree? I appreciate that there's a lot of files in the drivers/scsi/ directory, but c'mon. I had no idea what it was called and it took about 30 seconds to find them once I realised you wanted all the work to be done for you.

Thanks for looking this up. Would it be an acceptable approach if the SCST code is modified such that it calls the code inside drivers/scsi/scsi_tgt_lib.c whenever this is appropriate ?

From my point of view, the most important bit is the target layer <->

Quoted 3 lines · Bart Van Assche

Thanks for looking this up. Would it be an acceptable approach if the SCST code is modified such that it calls the code inside drivers/scsi/scsi_tgt_lib.c whenever this is appropriate ?

You need to talk to Mike and Tomo.

Quoted 1 line

From my point of view, the most important bit is the target layer <->

driver API. ie the transfer_response() method in the host template. I'm sure other people have their own preferences though.

Quoted 6 lines · Christoph Hellwig

Quoted 2 lines · Bart Van Assche

Regarding out-of-tree modules: this is just a preparatory step before submitting SCST for inclusion in the mainstream kernel.

And what crackpipe did you smoke to thing we'd put duplicated target framework in?

Why are you so aggressive ? I didn't insult you in any way.

Regarding inclusion of SCSI target code in the mainline, this subject has already been discussed extensively in the past
(http://lkml.org/lkml/2008/1/23/134). The conclusion was clear: SCST is faster than any other existing iSCSI target for Linux (IET, STGT, LIO), stable, well maintained and the most standards compliant target. Why do you want to reopen this discussion ?

James Bottomley clearly expressed in that thread that he doesn't want to maintain two SCSI target frameworks. So what I propose is that SCST is included in the mainline and afterwards that it is evaluated whether or not it is desirable to keep other target code in the mainline kernel.

Quoted 6 lines · Bart Van Assche

Regarding inclusion of SCSI target code in the mainline, this subject has already been discussed extensively in the past
(http://lkml.org/lkml/2008/1/23/134). The conclusion was clear: SCST is faster than any other existing iSCSI target for Linux (IET, STGT, LIO), stable, well maintained and the most standards compliant target. Why do you want to reopen this discussion ?

That's an interesting rewrite of history. The evidence you presented showed fairly identical results apart from on one contrived IB benchmark that couldn't directly compare the two.

I'm also on record in the thread saying that was insufficient proof for me to justify throwing STGT out and replacing it with SCST.

Quoted 5 lines

James Bottomley clearly expressed in that thread that he doesn't want to maintain two SCSI target frameworks. So what I propose is that SCST is included in the mainline and afterwards that it is evaluated whether or not it is desirable to keep other target code in the mainline kernel.

That's hardly sufficient. STGT is already in use. Their either has to be a migration path or, the preferred option, take the pieces of SCST that are actual improvements and embed them in STGT.

Quoted 5 lines · Bart Van Assche

James Bottomley clearly expressed in that thread that he doesn't want to maintain two SCSI target frameworks. So what I propose is that SCST is included in the mainline and afterwards that it is evaluated whether or not it is desirable to keep other target code in the mainline kernel.

That's hardly sufficient. STGT is already in use. Their either has to be a migration path or, the preferred option, take the pieces of SCST that are actual improvements and embed them in STGT.

I wrote all above to support my at first glance shocking conclusion that SCSI target subsystem is completely new subsystem of the kernel and it should live on its own with its own maintainer! This is the same as with the current interaction between SCSI and block subsystems in the kernel: SCSI uses block's functionality, but that doesn't mean that block and SCSI are the same subsystem.

Quoted 6 lines · Vladislav Bolkhovitin

I wrote all above to support my at first glance shocking conclusion that SCSI target subsystem is completely new subsystem of the kernel and it should live on its own with its own maintainer! This is the same as with the current interaction between SCSI and block subsystems in the kernel: SCSI uses block's functionality, but that doesn't mean that block and SCSI are the same subsystem.

Hello Tomo,

Due to the IET and STGT projects you have a lot of experience with implementing SCSI target frameworks. What is your opinion about how a kernel space SCSI target framework should fit in the Linux kernel ?

Bart, what is your role in the SCST project? You don't seem to have contributed any code to it (going by the SVN logs on sourceforge), and your questions and suggestions seem to be those of someone not familiar with the code. If you're not a developer, it might be more helpful for you to step back and let Vladislav handle this.

To answer your question: as you noticed, I did not yet contribute any code to the SCST project. I'm an iSCSI/iSER/SRP user. I'd like to have a SCSI target framework available on Linux that is as fast as possible, as reliable as possible, as standards compliant as possible, well maintained and for which all kernel code is integrated in the mainstream Linux kernel. I'm probably sharing this desire with all STGT, IET, SCST and LIO users. Do you consider the opinion of SCSI target framework users irrelevant in this discussion ?

Once Vladislav is ready for his project to be merged, let him approach us and ask. I don't know if he considers his project ready for merging. Did he ask you for his help? It's generally considered rather rude to merge someone else's code without their consent. The way you tried to get it merged was unhelpful and, if Vladislav were less skillful a communicator, could have actively hindered getting it merged.

To answer your question: as you noticed, I did not yet contribute any code to the SCST project. I'm an iSCSI/iSER/SRP user. I'd like to have a SCSI target framework available on Linux that is as fast as possible, as reliable as possible, as standards compliant as possible, well maintained and for which all kernel code is integrated in the mainstream Linux kernel. I'm probably sharing this desire with all STGT, IET, SCST and LIO users.

Quoted 7 lines · Bart Van Assche

Quoted 6 lines · Vladislav Bolkhovitin

I wrote all above to support my at first glance shocking conclusion that SCSI target subsystem is completely new subsystem of the kernel and it should live on its own with its own maintainer! This is the same as with the current interaction between SCSI and block subsystems in the kernel: SCSI uses block's functionality, but that doesn't mean that block and SCSI are the same subsystem.

Quoted 5 lines

Hello Tomo,

Due to the IET and STGT projects you have a lot of experience with implementing SCSI target frameworks. What is your opinion about how a kernel space SCSI target framework should fit in the Linux kernel ?

Bart, what is your role in the SCST project? You don't seem to have contributed any code to it (going by the SVN logs on sourceforge), and your questions and suggestions seem to be those of someone not familiar with the code. If you're not a developer, it might be more helpful for you to step back and let Vladislav handle this.

Quoted 6 lines · James Bottomley

Quoted 5 lines · Bart Van Assche

James Bottomley clearly expressed in that thread that he doesn't want to maintain two SCSI target frameworks. So what I propose is that SCST is included in the mainline and afterwards that it is evaluated whether or not it is desirable to keep other target code in the mainline kernel.

Quoted 3 lines

That's hardly sufficient. STGT is already in use. Their either has to be a migration path or, the preferred option, take the pieces of SCST that are actual improvements and embed them in STGT.

Actually, between SCSI initiator and target subsystems there is almost *nothing* in common. This claim, at first glance, looks pretty wrong, because both serve SCSI, so they must have a lot common. But look deeper and you quickly find out that the majority of functionality as well as data they use are dedicated for each subsystem, not shared.

Just look at SCST/qla2x00t/(changes done in the initiator qla2xxx driver to support target mode, patch attached): 90% of changes is adding callbacks for external target add-on, the rest is support for older, than 2.6.17, kernels and sysfs magic. Note, no data are common between initiator and target parts in the meaning that they both use them.

Then look at SCST (http://scst.sf.net). It implements complete pass-through SCSI support and look how it interacts with initiator SCSI subsystem. It calls only 2 functions: FIFO version of scsi_execute_async() (original scsi_execute_async() provides unacceptable LIFO commands order) and scsi_reset_provider() for task management. And there is only one common variable: struct scsi_device. That's all! In other storage modes (FILEIO/BLOCKIO) there is nothing common with SCSI initiator subsystem at all.

Finally, try to find out in SCST any duplicated functionality.

Now, let's look how SCSI target/initiator integration currently done in the kernel. For me it looks pretty artificial. For example, if I make a general purpose kernel, for which 1% of users would run target mode, I would have to enable as module "SCSI target support" as well as SCSI target support for transport attributes. Now 99% of users of my kernel, who don't need SCSI target, but need SCSI initiator drivers, would have to have scsi_tgt loaded, because transport attribute drivers would depend on it:

# lsmod
Module                  Size  Used by
qla2xxx               130844  0
firmware_class          8064  1 qla2xxx
scsi_transport_fc      40900  1 qla2xxx
scsi_tgt               12196  1 scsi_transport_fc
brd                     6924  0
xfs                   511280  1
dm_mirror              24368  0
dm_mod                 51148  1 dm_mirror
uhci_hcd               21400  0
sg                     31784  0
e1000                 114536  0
pcspkr                  3328  0

No target functionality needed, but target mode subsystem is needed. Is it a good design?

I wrote all above to support my at first glance shocking conclusion that SCSI target subsystem is completely new subsystem of the kernel and it should live on its own with its own maintainer! This is the same as with the current interaction between SCSI and block subsystems in the kernel: SCSI uses block's functionality, but that doesn't mean that block and SCSI are the same subsystem.

Thus, how IMHO initiator and target drivers should be written:

- All initiator drivers should live in the SCSI initiator subsystem
(aka current SCSI subsystem) only, the same as today.

- All target drivers should live in the SCSI target subsystem only and
be either add-ons to initiator drivers, like, e.g., qla2x00t, or be a complete driver, like, e.g., iSCSI-SCST.

Vlad

Quoted 6 lines · Bart Van Assche

Quoted 5 lines · Christoph Hellwig

Quoted 2 lines · Bart Van Assche

Regarding out-of-tree modules: this is just a preparatory step before submitting SCST for inclusion in the mainstream kernel.

And what crackpipe did you smoke to thing we'd put duplicated target framework in?

Quoted 8 lines

Why are you so aggressive ? I didn't insult you in any way.

Regarding inclusion of SCSI target code in the mainline, this subject has already been discussed extensively in the past
(http://lkml.org/lkml/2008/1/23/134). The conclusion was clear: SCST is faster than any other existing iSCSI target for Linux (IET, STGT, LIO), stable, well maintained and the most standards compliant target. Why do you want to reopen this discussion ?

That's an interesting rewrite of history. The evidence you presented showed fairly identical results apart from on one contrived IB benchmark that couldn't directly compare the two.

I'm also on record in the thread saying that was insufficient proof for me to justify throwing STGT out and replacing it with SCST.

Quoted 2 lines · Bart Van Assche

Regarding scsi_execute_async(): I didn't know that this API is on its way out. What will it be replaced by, and when ?

blk_execute_rq/blk_execute_rq_nowait plus the block level helpers built ontop to build requests.

Quoted 1 line

Bart.

---end quoted text---

Quoted 6 lines · Christoph Hellwig

Quoted 2 lines · Bart Van Assche

Regarding scsi_execute_async(): I didn't know that this API is on its way out. What will it be replaced by, and when ?

blk_execute_rq/blk_execute_rq_nowait plus the block level helpers built ontop to build requests.

scsi_execute_async() is already a nice and simple helper function on top blk_execute_rq_nowait(). What's the point then to remove it? Do you consider that exposing scsi_execute_async() internals to its users is better?

Quoted 3 lines

Quoted 1 line

Bart.

---end quoted text---

Quoted 8 lines · Vladislav Bolkhovitin

Quoted 5 lines · Christoph Hellwig

Quoted 2 lines · Bart Van Assche

Regarding scsi_execute_async(): I didn't know that this API is on its way out. What will it be replaced by, and when ?

blk_execute_rq/blk_execute_rq_nowait plus the block level helpers built ontop to build requests.

scsi_execute_async() is already a nice and simple helper function on top blk_execute_rq_nowait(). What's the point then to remove it? Do you consider that exposing scsi_execute_async() internals to its users is better?

The problem with it is the use of sg list to *hack* in bio's. Which totally ignores/duplicates block layer mechanisms. There is pending a large patchset that removes the use of scsi_execute_async from sg/sr and friends to use blk_map_*
members and directly call blk_execute_*. The original patchset was written by
Mike Christie but is now brought up to date by Tomo. It should be submitted soon I think.
If you need good example of usage check out bsg.c it maps user-space data in all kind
of combinations. If you have kernel space memory it is even simpler.

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

Bart.

---end quoted text---

If you need any help, please feel free to ask.

Boaz

Quoted 12 lines · Boaz Harrosh

Quoted 11 lines · Vladislav Bolkhovitin

Quoted 5 lines · Christoph Hellwig

Quoted 2 lines · Bart Van Assche

Regarding scsi_execute_async(): I didn't know that this API is on its way out. What will it be replaced by, and when ?

blk_execute_rq/blk_execute_rq_nowait plus the block level helpers built ontop to build requests.

scsi_execute_async() is already a nice and simple helper function on top blk_execute_rq_nowait(). What's the point then to remove it? Do you consider that exposing scsi_execute_async() internals to its users is better?

Quoted 7 lines

The problem with it is the use of sg list to *hack* in bio's. Which totally ignores/duplicates block layer mechanisms. There is pending a large patchset that removes the use of scsi_execute_async from sg/sr and friends to use blk_map_* members and directly call blk_execute_*. The original patchset was written by Mike Christie but is now brought up to date by Tomo. It should be submitted soon I think. If you need good example of usage check out bsg.c it maps user-space data in all kind of combinations. If you have kernel space memory it is even simpler.

Thanks for pointing on it. But it still remained unclear for me what's the point in the scsi_execute_async() removal. Function scsi_req_map_sg() looks pretty simple and straightforward, so I don't see how the overall code can be simplified.

Quoted 5 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

Bart.

---end quoted text---

If you need any help, please feel free to ask.

Quoted 10 lines · Vladislav Bolkhovitin

Quoted 9 lines · Boaz Harrosh

Quoted 8 lines · Vladislav Bolkhovitin

Quoted 5 lines · Christoph Hellwig

Quoted 2 lines · Bart Van Assche

Regarding scsi_execute_async(): I didn't know that this API is on its way out. What will it be replaced by, and when ?

blk_execute_rq/blk_execute_rq_nowait plus the block level helpers built ontop to build requests.

scsi_execute_async() is already a nice and simple helper function on top blk_execute_rq_nowait(). What's the point then to remove it? Do you consider that exposing scsi_execute_async() internals to its users is better?

Quoted 8 lines

Quoted 6 lines

The problem with it is the use of sg list to *hack* in bio's. Which totally ignores/duplicates block layer mechanisms. There is pending a large patchset that removes the use of scsi_execute_async from sg/sr and friends to use blk_map_*
members and directly call blk_execute_*. The original patchset was written by
Mike Christie but is now brought up to date by Tomo. It should be submitted soon I think.
If you need good example of usage check out bsg.c it maps user-space data in all kind
of combinations. If you have kernel space memory it is even simpler.

Thanks for pointing on it. But it still remained unclear for me what's the point in the scsi_execute_async() removal. Function scsi_req_map_sg() looks pretty simple and straightforward, so I don't see how the overall code can be simplified.

Well No, scsi_req_map_sg() is a complete hack. If you have user memory
or kernel memory you better go through blk_map_* which will take care of
device masks, alignment and all, where here the ULD does that. So you have
2 places of waisted code both at ULD to build the SG right, and here to translate SG to BIO. Where at block layer you have one function call.
Try it out you see that not using scsi_execute_async() is much more simple at ULD then using it. If you do mmap then Tomo has code for block layer to support that.

Quoted 26 lines · Boaz Harrosh

Quoted 20 lines · Vladislav Bolkhovitin

Quoted 12 lines · Boaz Harrosh

Quoted 11 lines · Vladislav Bolkhovitin

Quoted 5 lines · Christoph Hellwig

Quoted 2 lines · Bart Van Assche

Regarding scsi_execute_async(): I didn't know that this API is on its way out. What will it be replaced by, and when ?

blk_execute_rq/blk_execute_rq_nowait plus the block level helpers built ontop to build requests.

scsi_execute_async() is already a nice and simple helper function on top blk_execute_rq_nowait(). What's the point then to remove it? Do you consider that exposing scsi_execute_async() internals to its users is better?

Quoted 7 lines

The problem with it is the use of sg list to *hack* in bio's. Which totally ignores/duplicates block layer mechanisms. There is pending a large patchset that removes the use of scsi_execute_async from sg/sr and friends to use blk_map_* members and directly call blk_execute_*. The original patchset was written by Mike Christie but is now brought up to date by Tomo. It should be submitted soon I think. If you need good example of usage check out bsg.c it maps user-space data in all kind of combinations. If you have kernel space memory it is even simpler.

Quoted 5 lines

Thanks for pointing on it. But it still remained unclear for me what's the point in the scsi_execute_async() removal. Function scsi_req_map_sg() looks pretty simple and straightforward, so I don't see how the overall code can be simplified.

Quoted 8 lines

Well No, scsi_req_map_sg() is a complete hack. If you have user memory or kernel memory you better go through blk_map_* which will take care of device masks, alignment and all, where here the ULD does that. So you have 2 places of waisted code both at ULD to build the SG right, and here to translate SG to BIO. Where at block layer you have one function call. Try it out you see that not using scsi_execute_async() is much more simple at ULD then using it.
If you do mmap then Tomo has code for block layer to support that.

Seems, I'm starting understanding you. You mean that all ULDs (User Level Devices, i.e. sg, st, etc.) deal with user supplied buffers, i.e. pointers to virtually continuous memory, which at the moment it has to convert to SG vector, which then will be translated to BIOs for the corresponding LDD by scsi_execute_async() (and then back to SG vector on the queuecommand() time). So, it will be simpler to supply that buffer pointer directly to block functions. Correct?

But the problem is that in SCST in each data transfer 2 LDDs
participate: one target and one backstorage (initiator). And the target LDD deals with SG vectors only. So, SCST never deals with buffers, it always deals with SG vectors and pass them between target LDDs and backstorage as necessary.

Thus, looks like for SCST in the pass-through mode there is no alternative to scsi_execute_async().

Thanks,
Vlad

Quoted 27 lines · Vladislav Bolkhovitin

Quoted 26 lines · Boaz Harrosh

Quoted 10 lines · Vladislav Bolkhovitin

Quoted 9 lines · Boaz Harrosh

Quoted 8 lines · Vladislav Bolkhovitin

Quoted 5 lines · Christoph Hellwig

Quoted 2 lines · Bart Van Assche

Regarding scsi_execute_async(): I didn't know that this API is on its way out. What will it be replaced by, and when ?

blk_execute_rq/blk_execute_rq_nowait plus the block level helpers built ontop to build requests.

scsi_execute_async() is already a nice and simple helper function on top blk_execute_rq_nowait(). What's the point then to remove it? Do you consider that exposing scsi_execute_async() internals to its users is better?

Quoted 8 lines

Quoted 6 lines

The problem with it is the use of sg list to *hack* in bio's. Which totally ignores/duplicates block layer mechanisms. There is pending a large patchset that removes the use of scsi_execute_async from sg/sr and friends to use blk_map_*
members and directly call blk_execute_*. The original patchset was written by
Mike Christie but is now brought up to date by Tomo. It should be submitted soon I think.
If you need good example of usage check out bsg.c it maps user-space data in all kind
of combinations. If you have kernel space memory it is even simpler.

Thanks for pointing on it. But it still remained unclear for me what's the point in the scsi_execute_async() removal. Function scsi_req_map_sg() looks pretty simple and straightforward, so I don't see how the overall code can be simplified.

Well No, scsi_req_map_sg() is a complete hack. If you have user memory
or kernel memory you better go through blk_map_* which will take care of
device masks, alignment and all, where here the ULD does that. So you have
2 places of waisted code both at ULD to build the SG right, and here to translate SG to BIO. Where at block layer you have one function call.
Try it out you see that not using scsi_execute_async() is much more simple at ULD then using it. If you do mmap then Tomo has code for block layer to support that.

Quoted 3 lines

Seems, I'm starting understanding you. You mean that all ULDs (User Level Devices, i.e. sg, st, etc.) deal with user supplied buffers, i.e. pointers to virtually continuous memory, which at the moment it has to convert to SG vector, which then will be translated to BIOs for the corresponding LDD by scsi_execute_async() (and then back to SG vector on the queuecommand() time). So, it will be simpler to supply that buffer pointer directly to block functions. Correct?

But the problem is that in SCST in each data transfer 2 LDDs participate: one target and one backstorage (initiator). And the target LDD deals with SG vectors only. So, SCST never deals with buffers, it always deals with SG vectors and pass them between target LDDs and backstorage as necessary.

Where is that SG coming from? is it from Network stack? or is it an SG prepared by scsi-ml with call to blk_rq_map_sg()?

Quoted 2 lines

Thus, looks like for SCST in the pass-through mode there is no alternative to scsi_execute_async().

Tomo what do you think is it logical to add a blk function that will
accept an SG list and map it to a request. Like, for example, an SG from Network? opposite of what blk_rq_map_sg does.

Quoted 3 lines

Thanks,
Vlad

Boaz

Quoted 2 lines · Bart Van Assche

Regarding scsi_execute_async(): I didn't know that this API is on its way out. What will it be replaced by, and when ?

blk_execute_rq/blk_execute_rq_nowait plus the block level helpers built ontop to build requests.

Quoted 6 lines · Christoph Hellwig

Quoted 2 lines · Bart Van Assche

Regarding scsi_execute_async(): I didn't know that this API is on its way out. What will it be replaced by, and when ?

blk_execute_rq/blk_execute_rq_nowait plus the block level helpers built ontop to build requests.

Source reading learned me that the function scsi_execute_async() calls blk_execute_rq_nowait() with 1 as fourth argument, which means that the request is inserted at the head of the queue. This means that requests queued with scsi_execute_async() are executed before other queued requests, and that this function has LIFO (last in first out) semantics.

All non-SCSI calls to blk_execute_rq() / blk_execute_rq_nowait() add requests at the end of the queue (except those calls for terminating I/O).

What is the background of this special behavior of the SCSI subsystem ?

Quoted 15 lines · Bart Van Assche

Quoted 6 lines · Christoph Hellwig

Quoted 2 lines · Bart Van Assche

Regarding scsi_execute_async(): I didn't know that this API is on its way out. What will it be replaced by, and when ?

blk_execute_rq/blk_execute_rq_nowait plus the block level helpers built ontop to build requests.

Source reading learned me that the function scsi_execute_async() calls blk_execute_rq_nowait() with 1 as fourth argument, which means that the request is inserted at the head of the queue. This means that requests queued with scsi_execute_async() are executed before other queued requests, and that this function has LIFO (last in first out) semantics.

Quoted 5 lines

All non-SCSI calls to blk_execute_rq() / blk_execute_rq_nowait() add requests at the end of the queue (except those calls for terminating I/O).

What is the background of this special behavior of the SCSI subsystem ?

Is the linux-scsi mailing list the appropriate mailing list to post questions like the above ?

Am Donnerstag, den 08.05.2008, 17:02 +0200 schrieb Bart Van Assche:

Quoted 19 lines

Quoted 17 lines · Bart Van Assche

Quoted 5 lines · Christoph Hellwig

Quoted 2 lines · Bart Van Assche

Regarding scsi_execute_async(): I didn't know that this API is on its way out. What will it be replaced by, and when ?

blk_execute_rq/blk_execute_rq_nowait plus the block level helpers built ontop to build requests.

Source reading learned me that the function scsi_execute_async() calls blk_execute_rq_nowait() with 1 as fourth argument, which means that the request is inserted at the head of the queue. This means that requests queued with scsi_execute_async() are executed before other queued requests, and that this function has LIFO (last in first out) semantics.

All non-SCSI calls to blk_execute_rq() / blk_execute_rq_nowait() add requests at the end of the queue (except those calls for terminating I/O).

Quoted 3 lines

Quoted 1 line

What is the background of this special behavior of the SCSI subsystem ?

Is the linux-scsi mailing list the appropriate mailing list to post questions like the above ?

I guess this should
http://marc.info/?l=linux-scsi&m=116668527804801&w=2
answer your question.