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
41 matches
Mail list logo
