[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