AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:
CFG:
PT:0
S:andy.sharp@lsi.com
RQ:
SSV:mhbs.lsil.com
NSV:
SSH:
R:<Maxim.Kozlovsky@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/LSI/INBOX	0	861DA0537719934884B3D30A2666FECC010DFDE621@cosmail02.lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Thu, 28 Jan 2010 14:24:07 -0800
From: Andrew Sharp <andy.sharp@lsi.com>
To: "Kozlovsky, Maxim" <Maxim.Kozlovsky@lsi.com>
Subject: Re: review of changelist 33991
Message-ID: <20100128142407.5f307a45@ripper.onstor.net>
In-Reply-To: <861DA0537719934884B3D30A2666FECC010DFDE621@cosmail02.lsi.com>
References: <20100127171026.4f1226c2@ripper.onstor.net>
	<861DA0537719934884B3D30A2666FECC010DFDE621@cosmail02.lsi.com>
Organization: LSI
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Thu, 28 Jan 2010 11:48:14 -0700 "Kozlovsky, Maxim"
<Maxim.Kozlovsky@lsi.com> wrote:

> 
> 
> -----Original Message-----
> From: Andrew Sharp [mailto:andy.sharp@lsi.com] 
> Sent: Wednesday, January 27, 2010 5:10 PM
> To: Kozlovsky, Maxim
> Cc: Fisher, Bill
> Subject: review of changelist 33991
> 
> Finally finished this.  I removed all the "filename -- looks good"
> lines because it's just too huge.
> 
> In the future, please submit a separate changelist for mass
> script-based modifications like char8->int8 and like that, so that
> the entire changelist can be reviewed in one glance.
> 
> Thanks,
> 
> a
> 
> 
> Damnit, hit send button instead of menu button.
> 
> 
> = Change 33991 by maximk@maximk-13 on 2009/12/08 15:24:49 *pending*
> = 
> =         fix sm-scsi sm-evm-srvr sm-thread sm-fs sm-esm sm-scsi
> =                compilation.
> =                Reviewed by bfisher.
> = 
> 
> 
> fix reviewed by line, and add little more detail, for instance, you
> edited things like ssc-ssh-kbr, maybe you should explain why.
> 
> 
> linux/kernel/linux-mips-2.6/tuxstor-config
> 
>      I don't think you meant to include this, for obvious reasons
> [MK] ok
> 
> nfx-tree/Includes/bqueue.h
> 
>      this file is dead and moved.  please use the new version.  or
> move new version here and then make changes to it if you need to.
> [MK] This file is not dead, the user space code includes it. The
> change actually moves the changes from tpl/bqueue.h here, and changes
> all the references to tpl/bqueue.h so the files that are both in
> kernel and user space can compile.

OK, as long as you're convinced that your result has the changes from
the tpl/bqueue.h.

> nfx-tree/Includes/nfx-target.h
> 
>      i'm sorry, but we have two macros, one is SBM_REV2 and one is
>      SBM_REV_2?  now is the time to fix that
> [MK] No it is not the time 

Yes, please, now is the time.  I cannot understand what's going on with
these macros and the inconsistent use of them.

> nfx-tree/Includes/nfx-types.h
> 
>      line 24 the correct way to fix this is to make everything include
>      tpl/bqueue.h, or, to move tpl/bqueue.h to Inlcudes.
> [MK] This is exactly what is done

OK.

> nfx-tree/Makefile.tuxstor
> 
>      line 28, this is not the correct way to do this unless you want
> each of these directories to be a separate kernel module.  we don't
> want a blizzard of separate kernel modules.  a few is OK, but not a
> dozen. [MK] Yes I do want each of this directories to be a separate
> module.

Hokay, if that's what you want.

> nfx-tree/Tools/mkesm.pl
> 
>      line 786, already commented on
> [MK] see above
> 
> nfx-tree/code/neteee2/eee-app.c
> 
>      line 21, already commented on
> [MK] see above
> 
> nfx-tree/code/neteee2/eee-desc.c
> 
>      line 16 already commented on
> [MK] see above
> 
> nfx-tree/code/neteee2/eee-init.c
> 
>      line ?? already commented on.  i won't mention it from here on
> out. which means some files may be marked "looks good" when in fact
>      this needs to be addressed.  i have no problem if you want to
>      move bqueue from tpl directory to Includes directory, personally.
>      prolly should have done that from the beginning, but then it was
>      not tuxstor in the beginning.
> [MK] no see above
> 
> nfx-tree/code/neteee2/eee-timer-api.c
> 
>      line 634, we don't use this silliness any more.  rtczero is just
> 0. [MK] Apparently not, otherwise this will not be necessary.

It isn't necessary, that's my point.  I've removed it from all the
places it was used in the txrx side of things.

> nfx-tree/code/neteee2/eee-timer-api.h
> 
>      line 113 see previous comment
> [MK]
> 
> nfx-tree/code/neteee2/eee.h
> 
>      i'd rather that this sort of thing was in each individual file
> that required it.
> [MK] This file requires this.

I can't remember what I wrote this comment about.  Guess it's not
important.

> 
> nfx-tree/code/sm-esm/Makefile
> 
>      ok
> 
> nfx-tree/code/sm-esm/esm-nfx.c
> 
>      line 58 if the NFX_SPIN_LOCK macro is defined correctly, then
>      this change is not needed	
> [MK] Well you did not define it correctly.

It worked just fine for me without this.  Never mind, I can fix all
this later.

> nfx-tree/code/sm-evm-srvr/Makefile
> 
>      ok
> 
> nfx-tree/code/sm-evm-srvr/evm-msg.c
> 
>      ok
> 
> nfx-tree/code/sm-fs/Makefile
> 
>      this definitely doesn't look right to me.  i realize that
>      there might be some makefiles that have this dual mode, that
>      will be going away since we won't be doing a separate tuxrx
>      and tuxfp projects.  also, this will build the sm-fs directory
>      as a separate kernel module, which i doubt is what you want.
>      the rules for the generated code should be like real makefile
>      rules, not just a list of identical rules, one for each file.
> [MK] This file is used to compile user space and kernel hence the
> dual mode.

Userspace compiles in sm-fs?

> nfx-tree/code/sm-fs/btree/bt.h
> 
>      ok
> 
> nfx-tree/code/sm-fs/btree/emaproot.c
> 
>      line 776 FS_ELOG()/FS_TRACE() hasn't been ported over to the
>      "no-extra-paren" format?
> [MK] No
> 
> nfx-tree/code/sm-fs/fs-alloc.c
> 
>      line 2934 ... nice
> 
> nfx-tree/code/sm-fs/fs-eek-quota.c
> 
>      line 1089 don't you want to make these printks?  there are
> several others as well.
> [MK] ok
> 
> nfx-tree/code/sm-fs/fs-eek.c
> 
>      line 8628 i just noticed that you're using .counter all over the
>      place (in this and several other files) to directly peek/poke
>      at the value of an atomic_t.  you're not supposed to do that,
>      you're supposed to use that atomic_read() and atomic_set()
> methods. i realize that these are just #define's in mips (they are
> inlines in x86), but they can change the implementation and only have
> to support the access methods, not the structure definition.
> [MK] ok
> 
> nfx-tree/code/sm-fs/restore/restore.c
> 
>      line 39, this is silly.  please adopt the use of the <>.
> [MK] That's how everything is included and <> will not help here.
> Apparently the make file rules you produced are not quite right so
> that including that file in some other way does not work.

It does work, I used it extensively to solve this exact problem.

> nfx-tree/code/sm-fs/restore/seccache-api.h
> 
>      line 30 this is actually wrong, since the path inside "" is
>      relative to the file the does the including, not the header file.
>      switch to the <> syntax please.  especially for header files.
>      you won't have to mess with this stuff ever again.
> [MK] You are mistaken

Hardly.  But have it your way.  Of course, if you look, I never had to
add or delete any "../" to anything.

> nfx-tree/code/sm-fs/restore/tape.c
> 
>      line 44 again, use of the angle brackets would eliminate the need
>      for this nonsense.  please switch to using that syntax.
> [MK] No it would not, see above.

> nfx-tree/code/sm-fs/restore/utilities.c
> 
>      line 39 same as the others.  i won't belabor it anymore so some
>      files may have the problem will not be listed.
> 
> nfx-tree/code/sm-ispfc/ispfc.c
> 
>      line 115 please use the standard kernel methods for reading
>      registers (io.h)
> [MK] Why bother this code is going away anyway.

The ispfc code isn't going anywhere?  There's nothing to replace it in
the kernel that I know of.

> nfx-tree/linux.mk
> 
>      no, this is only done for ssc build
> [MK] PROD=tx is how ssc is compiled.

Damn.  I'll chat with you about this in person.
