Re: [Iscsitarget-devel] IET VPD 0x83h approach

[Luiz A. D. de L. <lui...@gm...>]

2008/3/25, Arne Redlich <ag...@po...>:
> Please avoid sending html messages and use plain text mails
>  instead. Thank you very much.

Sorry, I just used formated text for ascii-art. No more html...

>
>
>  "Luiz Angelo Daros de Luca" <lui...@gm...> writes:
>
>  > 2008/3/24, Ross S. W. Walker <rw...@me...>:
>  >
>  >     Luiz Angelo Daros de Luca wrote:
>  >     >
>
> >     > I needed to change IET to accept a hex based scsi and also to
>  >     > select the scsi_id type.
>  >
>  >     Not only will you need to modify both block-io.c and file-io.c
>  >     to set a hex scsi_id, you will need to create 2 new options as
>  >     well, one to set the vendor id and the other to set the
>  >     scsi_id type. The vendor id would be set in file-io.c and
>  >     block-io.c, but the scsi_id type will need to be set elsewhere.
>
>
> I don't think introducing ScsiIdType is a good idea at all, since it
>  restricts a LU to support only a single identification descriptor. I'd
>  favour specifying each desired descriptor seperately, e.g. sth. like
>  ScsiIdEUI64=0xdeadbeef,ScsiIdNAA=foobar,... - you get the idea.

Today IET suports just one SCSIID type. Udev, when inquiring scsi_id,
search for a list of id types. When the first is found, it gets
satisfied and exits. If I put many ID types, only the first asked
would be used.

>
>
>  >     > I just modified the block and not null and file ones. Is
>  >     > there any other solution to share code with all device types
>  >     > other than copy/paste? Is there anything similar to class
>  >     > heritage in c? Maintaining multiple equal code seems to be
>  >     > too manual job for me.
>  >
>  >     We talked about moving set_scsiid, gen_scsiid into volume.c
>  >     as it should be common to all back-end storage modules, but
>  >     then there was talk about re-doing how parameters are
>  >     parsed all together, doing it in user space versus kernel
>  >     space and before we knew it the scope was so large nobody
>  >     had time to do it.
>
>
> An overhaul of the param parsing would be /very/ nice indeed.
>
>
>  > Ok, I'll update it to 0.4.16.
>
>
> It would be even better to base patches on svn/trunk (though it is
>  identical to 0.4.16 at the moment). Also please have a look at the
>  Developer Notes in the README.
>

I'll try 0.4.16 by now and recheck it with svn when I finish. I'll
take a look at README.

>  Thanks,
>

Thanks,

> Arne
>



-- 
      Luiz Angelo Daros de Luca
            lui...@gm...
              ICQ: 19290419

 I Know, "Where you wanted to go today",
    but I decided to stop here instead!
                        MS Windows