[Stgt-devel] [Patch 1/2] Add-new-module-entry-points-for-configuration - Try 5
FUJITA Tomonori
fujita.tomonori
Tue Jun 12 14:37:06 CEST 2007
From: "Mark Harvey" <markh794 at gmail.com>
Subject: Re: [Stgt-devel] [Patch 1/2] Add-new-module-entry-points-for-configuration - Try 5
Date: Tue, 12 Jun 2007 14:32:59 +1000
> > > struct scsi_lu {
> > > int fd;
> > > uint64_t addr; /* persistent mapped address */
> > > uint64_t size;
> > > uint64_t lun;
> > > - char scsi_id[SCSI_ID_LEN];
> > > - char scsi_sn[SCSI_SN_LEN];
> > > char *path;
> > >
> > > /* the list of devices belonging to a target */
> > > @@ -48,7 +63,7 @@ struct scsi_lu {
> > > uint64_t reserve_id;
> > >
> > > /* TODO: needs a structure for lots of device parameters */
> > > - uint8_t d_sense;
> > > + struct lu_phy_attr *attributes;
> >
> > Why do we use a struct lu_phy_attr pointer? Why just can't we do:
> >
> > struct scsi_lu {
> > ...
> > struct lu_phy_attr attrs;
> > };
> >
> > 'attributes' is too long for me. renamed 'attrs'.
> >
>
> I used a pointer and malloc(sizeof(struct lu_phy_attrs)) thinking this
> will limit the size of the scsi_lu structure.
What's the point to use a pointer (and reduce the the scsi_lu
structure size) if we always allocate a lu_phy_attr structure for each
scsi_lu?
> I can in-line it with scsi_lu if you like..
>
>
> BTW: I am having problem accessing the git repositry via http..
> (git:// blocked from work's firewall)
Sorry, I have no idea. dumping the current your tree and
git-clone might work.
More information about the stgt
mailing list