On Wed, 2018-04-11 at 17:45 -0400, Douglas Gilbert wrote:
> It is a good bet that some sg based apps in the wild will be using the
> old (shifted+masked) SCSI status defines. The basis of the sg_v3 interface
> is 'struct sg_io_hdr' and it has two SCSI status fields: 'status' and
> 'masked_status'.
On 2018-04-11 12:25 PM, Johannes Thumshirn wrote:
On Wed, Apr 11, 2018 at 12:20:49PM -0400, Martin K. Petersen wrote:
Johannes,
While we're at it, anyone still in love with the non SAM_ status
bytes? If not they'll be gone afterwards as well.
/me is up for some spring cleaning.
Just be
On Wed, Apr 11, 2018 at 12:20:49PM -0400, Martin K. Petersen wrote:
>
> Johannes,
>
> > While we're at it, anyone still in love with the non SAM_ status
> > bytes? If not they'll be gone afterwards as well.
> >
> > /me is up for some spring cleaning.
>
> Just be careful not to break any sg/bsg
Johannes,
> While we're at it, anyone still in love with the non SAM_ status
> bytes? If not they'll be gone afterwards as well.
>
> /me is up for some spring cleaning.
Just be careful not to break any sg/bsg apps that rely on them.
--
Martin K. Petersen Oracle Linux Engineering
On Wed, Apr 11, 2018 at 12:05:18PM -0400, Martin K. Petersen wrote:
>
> Johannes,
>
> > Well it's defined in "drivers/scsi/scsi_typedefs.h" and only used by
> > some (old) drivers inside drivers/scsi so it can't be a UAPI => we're
> > not breaking any existing user-space with it.
>
> I'm all
Johannes,
> Well it's defined in "drivers/scsi/scsi_typedefs.h" and only used by
> some (old) drivers inside drivers/scsi so it can't be a UAPI => we're
> not breaking any existing user-space with it.
I'm all for nuking it.
> Anyways that's still WIP but I plan to have it done before LSF/MM so
On Tue, Apr 10, 2018 at 02:53:40PM +, Bart Van Assche wrote:
> I'm in favor of the removal. But maybe there is something I'm overlooking
> and that means that the typedef should not be removed?
Well it's defined in "drivers/scsi/scsi_typedefs.h" and only used by
some (old) drivers inside
On Tue, 2018-04-10 at 15:48 +0200, Johannes Thumshirn wrote:
> On Mon, Apr 09, 2018 at 09:35:21PM -0400, Martin K. Petersen wrote:
> >
> > Johannes,
> >
> > > I did start a series [1] for this but than got distracted by more urgent
> > > things. I can pick it up again I think.
> > >
> > > [1]
>
Hi,
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 19.8603)
The bot has tested the following trees: v4.16.1, v4.15.16, v4.14.33, v4.9.93,
v4.4.127.
v4.16.1: Failed to apply!
On Mon, Apr 09, 2018 at 09:35:21PM -0400, Martin K. Petersen wrote:
>
> Johannes,
>
> > I did start a series [1] for this but than got distracted by more urgent
> > things. I can pick it up again I think.
> >
> > [1]
> >
Johannes,
> I did start a series [1] for this but than got distracted by more urgent
> things. I can pick it up again I think.
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/jth/linux.git/log/?h=iscsi_DID_REQUEUE
Definitely a step in the right direction.
--
Martin K. Petersen
Bart,
> A recent change in the SCSI core caused certain request failures no
> longer to be reported to user space. Damien noticed this by sending a
> write request that is not aligned to the write pointer to an SMR drive
> from user space. Such non-aligned write requests are failed by the
>
On Fri, Apr 06, 2018 at 02:59:16PM +, Bart Van Assche wrote:
> On Fri, 2018-04-06 at 09:45 +0200, Johannes Thumshirn wrote:
> > On 05/04/18 19:49, Martin K. Petersen wrote:
> > > Longer term I'd really like to see the command result integer
> > > host/driver/msg/status stuff cleaned up. It's
On Fri, 2018-04-06 at 09:45 +0200, Johannes Thumshirn wrote:
> On 05/04/18 19:49, Martin K. Petersen wrote:
> > Longer term I'd really like to see the command result integer
> > host/driver/msg/status stuff cleaned up. It's super arcane and the
> > associated naming schemes make it a very
On 05/04/18 19:49, Martin K. Petersen wrote:
>
> Bart,
>
>> A recent change in the SCSI core caused certain request failures no
>> longer to be reported to user space. Damien noticed this by sending a
>> write request that is not aligned to the write pointer to an SMR drive
>> from user space.
Bart,
> A recent change in the SCSI core caused certain request failures no
> longer to be reported to user space. Damien noticed this by sending a
> write request that is not aligned to the write pointer to an SMR drive
> from user space. Such non-aligned write requests are failed by the
>
16 matches
Mail list logo
