public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Hannes Reinecke <hare@suse.de>
Cc: "Wangshen (C)" <peter.w@huawei.com>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"Jinbo (Justin)" <jinbo@huawei.com>
Subject: Re: Is there any plan to support 64bit lun in mainline?
Date: Mon, 14 Oct 2013 19:30:49 +0100	[thread overview]
Message-ID: <1381775449.3752.9.camel@dabdike.lan> (raw)
In-Reply-To: <525BC836.2030306@suse.de>

On Mon, 2013-10-14 at 12:32 +0200, Hannes Reinecke wrote:
> On 10/12/2013 08:35 AM, Wangshen (C) wrote:
> > Hello everyone,
> > 
> > My name is Wang Shen.
> > I am developing some scsi devices in Linux needs 64bit lun.
> > Now I am in trouble in scsi driver programming.
> > 
> > According to SAM-5, a LUN structure is 8 bytes long, but it is only 4 bytes long in kernel.
> > In another word Linux kernel only supports single level LUN, except conglomerate LUN and Hierarchical LUN.
> > In my project, we need support all of the LUN structures.
> > 
> > I find an archive mail on Tue, 19 Feb 2013 which discussed "scsi: 64-bit LUN support", but it just a patchset.
> > 
> > Is there any plan to merge this patchset to mainline?
> > If there is a plan, Which version will support 64bit lun?
> 
> Yes, there is a plan. Sort of.
> 
> I have a patchset (basically an update from the original patches)
> sitting here in my private repository.
> 
> However, there are two other patchsets pending (EH Deadline and
> asynchronous command aborts), both of which have been tested
> thoroughly _and_ have acked-by from various other parties.
> None of these patchset had received any feedback from James
> Bottomley, let alone any indication if or when they'll be merged.
> 
> So I stopped sending further patchsets, sensing some communication
> breakdown on the line.

There's no communications breakdown, I've just been very busy.  EH
deadline looks OK, but let me look again to make sure.  Async aborts I'm
not necessarily keen on because I know a lot of devices where aborting
just confuses the firmware more, so I think skipping aborts and moving
to LUN reset might be a better form of acceleration.

James 

> I try to excite some response from James B. next week in Edinburgh.
> At the very least there'll be other persons with whom I'll be able
> to discuss further steps.
> 
> And yes, this is slightly irritating.
> 
> Cheers,
> 
> Hannes




  parent reply	other threads:[~2013-10-14 18:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-12  6:35 Is there any plan to support 64bit lun in mainline? Wangshen (C)
2013-10-14 10:32 ` Hannes Reinecke
2013-10-14 15:29   ` Christoph Hellwig
2013-10-20 16:20     ` Douglas Gilbert
2013-10-14 18:30   ` James Bottomley [this message]
2013-10-15  6:01     ` Hannes Reinecke
2013-10-15 14:58       ` James Bottomley
2013-10-16  4:11       ` Vladislav Bolkhovitin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1381775449.3752.9.camel@dabdike.lan \
    --to=james.bottomley@hansenpartnership.com \
    --cc=hare@suse.de \
    --cc=jinbo@huawei.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=peter.w@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox