Re: [PATCH 9/9] bsg: split handling of SCSI CDBs vs transport requeues

2017-10-24 Thread Jens Axboe
On 10/23/2017 01:17 AM, Martin K. Petersen wrote: > > Christoph, > >>> Yes, I expected the bsg bits to go through Jens' tree. >> >> Ok, then I misremembered it, and we'll have to delay the remaining >> patches until the next merge window, as they depend on the previous >> ones. > > I don't mind

Re: [PATCH 9/9] bsg: split handling of SCSI CDBs vs transport requeues

2017-10-24 Thread Benjamin Block
> +static int bsg_transport_complete_rq(struct request *rq, struct sg_io_v4 > *hdr) > +{ > + struct bsg_job *job = blk_mq_rq_to_pdu(rq); > + int ret = 0; > + > + /* > + * The assignments below don't make much sense, but are kept for > + * bug by bug backwards compatibility:

Re: [PATCH 9/9] bsg: split handling of SCSI CDBs vs transport requeues

2017-10-23 Thread Martin K. Petersen
Christoph, >> Yes, I expected the bsg bits to go through Jens' tree. > > Ok, then I misremembered it, and we'll have to delay the remaining > patches until the next merge window, as they depend on the previous > ones. I don't mind taking them through SCSI if Jens agrees. -- Martin K. Petersen

Re: [PATCH 9/9] bsg: split handling of SCSI CDBs vs transport requeues

2017-10-23 Thread Christoph Hellwig
On Mon, Oct 23, 2017 at 02:16:03AM -0400, Martin K. Petersen wrote: > > Benjamin, > > >> Not sure it's worth it especially now that Martin has merged the patch. > > > > He did? I only saw a mail that he picked patches 2-5. So all the bsg > > changes are still open I think. > > Yes, I expected

Re: [PATCH 9/9] bsg: split handling of SCSI CDBs vs transport requeues

2017-10-23 Thread Martin K. Petersen
Benjamin, >> Not sure it's worth it especially now that Martin has merged the patch. > > He did? I only saw a mail that he picked patches 2-5. So all the bsg > changes are still open I think. Yes, I expected the bsg bits to go through Jens' tree. -- Martin K. Petersen Oracle Linux

Re: [PATCH 9/9] bsg: split handling of SCSI CDBs vs transport requeues

2017-10-20 Thread Benjamin Block
On Fri, Oct 20, 2017 at 06:26:30PM +0200, Christoph Hellwig wrote: > On Thu, Oct 19, 2017 at 05:59:33PM +0200, Benjamin Block wrote: > > > +#define ptr64(val) ((void __user *)(uintptr_t)(val)) > > > > Better to reflect the special property, that it is a user pointer, in > > the name of the macro.

Re: [PATCH 9/9] bsg: split handling of SCSI CDBs vs transport requeues

2017-10-20 Thread Christoph Hellwig
On Thu, Oct 19, 2017 at 05:59:33PM +0200, Benjamin Block wrote: > > +#define ptr64(val) ((void __user *)(uintptr_t)(val)) > > Better to reflect the special property, that it is a user pointer, in > the name of the macro. Maybe something like user_ptr(64). The same > comment for the same macro in

Re: [PATCH 9/9] bsg: split handling of SCSI CDBs vs transport requeues

2017-10-19 Thread Benjamin Block
Hey Christoph, better late than never I guess. On Tue, Oct 03, 2017 at 12:48:45PM +0200, Christoph Hellwig wrote: > The current BSG design tries to shoe-horn the transport-specific passthrough > commands into the overall framework for SCSI passthrough requests. This > has a couple problems: > >

Re: [PATCH 9/9] bsg: split handling of SCSI CDBs vs transport requeues

2017-10-04 Thread Johannes Thumshirn
On Wed, Oct 04, 2017 at 09:20:59AM +0200, Christoph Hellwig wrote: > It's a different level of callback - ops are the type of request > passed through (scsi vs transport) and ->release is s whacky > implementation detail of the SAS passthrough. If at all ->release > should go away eventually by

Re: [PATCH 9/9] bsg: split handling of SCSI CDBs vs transport requeues

2017-10-04 Thread Christoph Hellwig
On Wed, Oct 04, 2017 at 09:18:11AM +0200, Johannes Thumshirn wrote: > Wouldn't it make sense to put the ->release() method into bsg_ops as > well? The current prototype of bsg_register_queue isn't exactly what I > would call a sane API. It's a different level of callback - ops are the type of

Re: [PATCH 9/9] bsg: split handling of SCSI CDBs vs transport requeues

2017-10-04 Thread Johannes Thumshirn
Christoph Hellwig writes: [...] > @@ -965,7 +932,8 @@ void bsg_unregister_queue(struct request_queue *q) > EXPORT_SYMBOL_GPL(bsg_unregister_queue); > > int bsg_register_queue(struct request_queue *q, struct device *parent, > -const char *name, void

Re: [PATCH 9/9] bsg: split handling of SCSI CDBs vs transport requeues

2017-10-04 Thread Johannes Thumshirn
Christoph Hellwig writes: [...] > @@ -965,7 +932,8 @@ void bsg_unregister_queue(struct request_queue *q) > EXPORT_SYMBOL_GPL(bsg_unregister_queue); > > int bsg_register_queue(struct request_queue *q, struct device *parent, > -const char *name, void

Re: [PATCH 9/9] bsg: split handling of SCSI CDBs vs transport requeues

2017-10-04 Thread Hannes Reinecke
On 10/03/2017 12:48 PM, Christoph Hellwig wrote: > The current BSG design tries to shoe-horn the transport-specific passthrough > commands into the overall framework for SCSI passthrough requests. This > has a couple problems: > > - each passthrough queue has to set the

[PATCH 9/9] bsg: split handling of SCSI CDBs vs transport requeues

2017-10-03 Thread Christoph Hellwig
The current BSG design tries to shoe-horn the transport-specific passthrough commands into the overall framework for SCSI passthrough requests. This has a couple problems: - each passthrough queue has to set the QUEUE_FLAG_SCSI_PASSTHROUGH flag despite not dealing with SCSI commands at all.