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
> +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:
>
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
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 th
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 Enginee
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.
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 b
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:
>
>
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 cl
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 requ
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 (*release)(struct device
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 (*release)(struct device
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 QUEUE_FLAG_SCSI_PASSTHROU
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.
14 matches
Mail list logo
