Luben Tuikov wrote:
> --- Stefan Richter <[EMAIL PROTECTED]> wrote:
>> Among else: It should provide a framework which enables userspace to
>> find the unique object identifiers (that are required to uniquely and
>> persistently identify logical units) always in the same place. (That's
>> just my
--- Stefan Richter <[EMAIL PROTECTED]> wrote:
> SAM itself speaks of the LUN as 8 bytes quantity as well as 64 bits
> quantity (and 2 bytes quantity as well as 16 bits quantity). Of course
> whether this dualism should be exposed in an API is another question.
"64 bit quantity", the keyword here
Luben Tuikov wrote:
> --- Stefan Richter <[EMAIL PROTECTED]> wrote:
>> How about:
>>
>> union scsi_lun {
>> __u8lun[8];
>> __be64 lun64;
>> __be16 lun16;
>> };
>
> I'd rather not even hint that a LUN is to be viewed
> as anything integer-like. Just use u8[8] aligned.
>
> (I.
--- Stefan Richter <[EMAIL PROTECTED]> wrote:
> How about:
>
> union scsi_lun {
> __u8lun[8];
> __be64 lun64;
> __be16 lun16;
> };
I'd rather not even hint that a LUN is to be viewed
as anything integer-like. Just use u8[8] aligned.
(I.e. it is u64 only at the time when
Luben Tuikov wrote:
> In fact, I'd do
> typedef __u8 lun_t[8];
> and then define the macro
> #define LUN_TO_U64(_lun) ((unsigned long long) be64_to_cpu(*(__be64
> *)(_lun)))
Don't forget __attribute__((aligned(8))) on lun_t then. Some
architectures need it.
The macro should perhaps be calle
--- Swen Schillig <[EMAIL PROTECTED]> wrote:
> I think Luben and Stefan suggested a good way to do that, ok apart from the
> be64 bits :-)
What is the objection to the use of be64_to_cpu()?
> So, just use the struct scsi_lun in its full extend, for the sysfs without a
> leading "0x",
> and forg
On Monday 25 June 2007 16:03, Hannes Reinecke wrote:
> Swen Schillig wrote:
> > On Friday 22 June 2007 16:11, James Bottomley wrote:
> >> On Thu, 2007-06-21 at 21:40 -0700, Mike Anderson wrote:
> >>> James Bottomley <[EMAIL PROTECTED]> wrote:
> A proposal to display the correct form of the LUN
James Bottomley wrote:
> On Tue, 2007-06-26 at 17:47 +0200, Stefan Richter wrote:
>> To fill values into these attributes, transport layer
>> drivers/classes/whatever supply to SCSI core either strings or functions
>> which print strings into buffers. -> SCSI core controls that these
>> propertie
On Mon, Jun 25, 2007 at 02:27:01PM -0700, Luben Tuikov wrote:
> Ideally SCSI Core is presented with an opaque token (void *, unsigned long
> (long),
> etc) which represents a target port, which it uses to send SPC commands
> to the target to find out how many if any LUs the target has, INQUIRY the
On Tue, 2007-06-26 at 17:47 +0200, Stefan Richter wrote:
> James Bottomley wrote:
> > On Tue, 2007-06-26 at 12:44 +0200, Stefan Richter wrote:
> >> If there are going to be sysfs representations of targets,
> [...]
> > OK, you've lost me ... this is our current sysfs representation of a
> > disk:
>
James Bottomley wrote:
> On Tue, 2007-06-26 at 12:44 +0200, Stefan Richter wrote:
>> If there are going to be sysfs representations of targets,
[...]
> OK, you've lost me ... this is our current sysfs representation of a
> disk:
>
> /sys/devices/pci:00/:00:1f.1/host0/target0:0:0/0:0:0:0
>
On Tue, 2007-06-26 at 12:44 +0200, Stefan Richter wrote:
> Luben Tuikov wrote:
> > --- Stefan Richter <[EMAIL PROTECTED]> wrote:
> >> Do all these transports use the same *name* for the attribute holding
> >> the target port identifier's?
> >
> > Sure, it is "tpid".
>
> In mainline's transport cl
Luben Tuikov wrote:
> --- Stefan Richter <[EMAIL PROTECTED]> wrote:
>> Do all these transports use the same *name* for the attribute holding
>> the target port identifier's?
>
> Sure, it is "tpid".
In mainline's transport classes? Or/and in your stack? OK, I'm lazy, I
should look into the sourc
Luben Tuikov wrote:
> Display this:
> "%016llx", ((unsigned long long) be64_to_cpu(*(__be64 *)(LUN))),
> where LUN is u8[8]. Notice the ugly, C-centric "0x" prefix
> is missing.
I agree. We don't need 0x prefix nor h suffix nor delimiters like
spaces, dashes, colons... in the kernel's printouts
--- Stefan Richter <[EMAIL PROTECTED]> wrote:
> Do all these transports use the same *name* for the attribute holding
> the target port identifier's?
Sure, it is "tpid".
> In other words, is userspace able to find
> the target port identifier without knowing which transport is at work?
How can t
--- James Bottomley <[EMAIL PROTECTED]> wrote:
> You're sort of confusing what we display as the LUN and what we
> represent it as internally (admittedly they're the same at the moment).
> The object would be to separate these and the debate is really about
> what to display.
Display this:
"%016l
--- Stefan Richter <[EMAIL PROTECTED]> wrote:
> My thought was that SCSI core's role would only be to create the
> respective sysfs attributes (thus enforcing uniform naming of the
> attributes), but that the transport layer implementations are
> responsible to feed string representations there; in
Luben Tuikov wrote:
> Indeed it is more accurate to represent LUNs in 64 bit format.
>
> It is even more accurate to represent them as u8 LUN[8], and possibly
> print them as
> "0x%016llx" ((unsigned long long) be64_to_cpu(*(__be64 *)(LUN))).
Might need a little precaution on some architectur
James Bottomley wrote:
> On Mon, 2007-06-25 at 20:57 +0200, Stefan Richter wrote:
>> I would also like to have the Target Port identifier in there. This, in
>> combination with the LUN alias Logical Unit identifier is useful for all
>> kinds of persistent device mapping.
>
> Really, no. Target p
Luben Tuikov wrote:
> --- Stefan Richter <[EMAIL PROTECTED]> wrote:
>> I would also like to have the Target Port identifier in there.
("in there" = in sysfs)
> Well this is not correct because the TPI's format and representation
> is transport dependent
My thought was that SCSI core's role would
On Mon, 2007-06-25 at 20:57 +0200, Stefan Richter wrote:
> Hannes Reinecke wrote:
> > why don't we stick with the original implementation like zfcp had it?
> > We can simpley expand the midlayer to add an attribute 'lun'
> > to each scsi_device. This would be the LUN as returned by eg
> > REPORT LU
--- Stefan Richter <[EMAIL PROTECTED]> wrote:
> Hannes Reinecke wrote:
> > why don't we stick with the original implementation like zfcp had it?
> > We can simpley expand the midlayer to add an attribute 'lun'
> > to each scsi_device. This would be the LUN as returned by eg
> > REPORT LUNS.
> > No
--- Doug Maxey <[EMAIL PROTECTED]> wrote:
> On Fri, 22 Jun 2007 09:11:39 CDT, James Bottomley wrote:
> > On Thu, 2007-06-21 at 21:40 -0700, Mike Anderson wrote:
> > > James Bottomley <[EMAIL PROTECTED]> wrote:
> > > > A proposal to display the correct form of the LUN would be useful if you
> > > >
--- James Bottomley <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-06-21 at 21:40 -0700, Mike Anderson wrote:
> > James Bottomley <[EMAIL PROTECTED]> wrote:
> > > A proposal to display the correct form of the LUN would be useful if you
> > > wish to make it? ... The problem is really that SAM specifies
Hannes Reinecke wrote:
> why don't we stick with the original implementation like zfcp had it?
> We can simpley expand the midlayer to add an attribute 'lun'
> to each scsi_device. This would be the LUN as returned by eg
> REPORT LUNS.
> No translation, nothing. Would be easy to implement and would
Swen Schillig wrote:
> On Friday 22 June 2007 16:11, James Bottomley wrote:
>> On Thu, 2007-06-21 at 21:40 -0700, Mike Anderson wrote:
>>> James Bottomley <[EMAIL PROTECTED]> wrote:
A proposal to display the correct form of the LUN would be useful if you
wish to make it? ... The problem
On Friday 22 June 2007 16:11, James Bottomley wrote:
> On Thu, 2007-06-21 at 21:40 -0700, Mike Anderson wrote:
> > James Bottomley <[EMAIL PROTECTED]> wrote:
> > > A proposal to display the correct form of the LUN would be useful if you
> > > wish to make it? ... The problem is really that SAM spe
James Bottomley wrote:
> H:C is really mid-layer defined (although I'd like to get rid of C
> eventually). They really correspond to physical enumeration of the HBA
> devices. T (or I) is the one we think could be abstracted and placed
> within the gift of the transport, but so far there's been a
On Fri, 22 Jun 2007 09:11:39 CDT, James Bottomley wrote:
> On Thu, 2007-06-21 at 21:40 -0700, Mike Anderson wrote:
> > James Bottomley <[EMAIL PROTECTED]> wrote:
> > > A proposal to display the correct form of the LUN would be useful if you
> > > wish to make it? ... The problem is really that SA
On Thu, 2007-06-21 at 21:40 -0700, Mike Anderson wrote:
> James Bottomley <[EMAIL PROTECTED]> wrote:
> > A proposal to display the correct form of the LUN would be useful if you
> > wish to make it? ... The problem is really that SAM specifies a
> > possible 4 level structure with 4 possible addre
On Thu, Jun 21, 2007 at 09:40:35PM -0700, Mike Anderson wrote:
> James Bottomley <[EMAIL PROTECTED]> wrote:
> > A proposal to display the correct form of the LUN would be useful if you
> > wish to make it? ... The problem is really that SAM specifies a
> > possible 4 level structure with 4 possibl
James Bottomley <[EMAIL PROTECTED]> wrote:
> A proposal to display the correct form of the LUN would be useful if you
> wish to make it? ... The problem is really that SAM specifies a
> possible 4 level structure with 4 possible address methods per level.
>
> The well known LUNs should be simple;
On Thu, 2007-06-21 at 18:46 +0200, Stefan Richter wrote:
> For example, the SCSI midlayer H:C:T:L tuple is useless for
> SBP-2-attached devices. What is useful is the ieee1394_id sysfs
> attribute which we expose as a scsi_device's sysfs attribute. This
> attribute was something implementation-de
On Thu, 2007-06-21 at 17:03 +0200, Christof Schmitt wrote:
> Now that everybody is happy with using the FCP LUN in the SCSI
> midlayer, this raises a question from the user's perspective:
>
> sysfs and lsscsi display the LUN as decimal number. For the FCP LUN
> 0x401040c3, sysfs and lsscsi
> the SCSI midlayer H:C:T:L
NB, the H, C, T, and L therein are implementation-defined things and not
to be mistaken for actual SCSI identifiers or names.
--
Stefan Richter
-=-=-=== -==- =-=-=
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the
Christof Schmitt wrote:
> sysfs and lsscsi display the LUN as decimal number. For the FCP LUN
> 0x401040c3, sysfs and lsscsi display this:
>
> $ ls -l /sys/bus/scsi/devices/
> total 0
> lrwxrwxrwx 1 root root 0 Jun 21 16:49 0:0:0:1086537744 ->
> ../../../devices/css0/0.0.0010/0.0.181d/host
Now that everybody is happy with using the FCP LUN in the SCSI
midlayer, this raises a question from the user's perspective:
sysfs and lsscsi display the LUN as decimal number. For the FCP LUN
0x401040c3, sysfs and lsscsi display this:
$ ls -l /sys/bus/scsi/devices/
total 0
lrwxrwxrwx 1 r
On Tue, 2007-06-19 at 18:12 +0100, Christoph Hellwig wrote:
> fcp_lun is an unsigned long long (and should be a __be64), so casting
> this to a struct type is not very nice. Care to add a version that
> takes
> a __be64 intead? In fact using that variant in scsi_scan.c might be
> benefical aswell
On Tue, Jun 19, 2007 at 10:25:30AM +0200, Swen Schillig wrote:
> + unit->scsi_lun = scsilun_to_int((struct scsi_lun *)&unit->fcp_lun);
> +
fcp_lun is an unsigned long long (and should be a __be64), so casting
this to a struct type is not very nice. Care to add a version that takes
a __be
Swen Schillig wrote:
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -1213,7 +1213,7 @@ static void scsi_sequential_lun_scan(struct scsi_target
> *starget,
> * Given a struct scsi_lun of: 0a 04 0b 03 00 00 00 00, this function
> returns
> * the integer: 0x0b030a
Swen Schillig wrote:
> From: Christof Schmitt <[EMAIL PROTECTED]>
>
> When reporting SCSI devices to the SCSI midlayer, use the FCP LUN as
> LUN reported to the SCSI layer. With this approach, zfcp does not have
> to create unique LUNS, and this code can be removed.
>
> Signed-off-by: Christof Sc
From: Christof Schmitt <[EMAIL PROTECTED]>
When reporting SCSI devices to the SCSI midlayer, use the FCP LUN as
LUN reported to the SCSI layer. With this approach, zfcp does not have
to create unique LUNS, and this code can be removed.
Signed-off-by: Christof Schmitt <[EMAIL PROTECTED]>
Signed-of
42 matches
Mail list logo
