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:<Rendell.Fong@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/LSI/INBOX	0	1268262525.16781.529.camel@rendellf
X-Sylpheed-End-Special-Headers: 1
Date: Wed, 10 Mar 2010 16:01:42 -0800
From: Andrew Sharp <andy.sharp@lsi.com>
To: Rendell Fong <Rendell.Fong@lsi.com>
Subject: Re: please review - 34392
Message-ID: <20100310160142.03342b73@ripper.onstor.net>
In-Reply-To: <1268262525.16781.529.camel@rendellf>
References: <1268165053.16781.463.camel@rendellf>
	<20100310105856.439da579@ripper.onstor.net>
	<1268262525.16781.529.camel@rendellf>
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 Wed, 10 Mar 2010 16:08:45 -0700 Rendell Fong <Rendell.Fong@lsi.com>
wrote:

> On Wed, 2010-03-10 at 11:58 -0700, Andrew Sharp wrote:
> > On Tue, 9 Mar 2010 13:04:13 -0700 Rendell Fong
> > <Rendell.Fong@lsi.com> wrote:
> > 
> > > Change 34392 by rendellf@rendellf-test on 2010/02/04 18:41:02
> > > *pending*
> > > 
> > >  Clean up of chassis mgr code by removing obsolete Bobcat and
> > > Cheetah ifdef'd cases.  Removed unneeded references to chassis
> > > mgr header files in other various files.  Added new card type for
> > > Cougar platform and cpu state mgmt api routines.  Deleted txrx/fp
> > > chassis code since it has been replaced by user app code "cm".
> > > Replaced use of sendAgile messages with rmc.
> > > 
> > > Affected files ...
> > > 
> > > ... //depot/tuxrx/linux/kernel/linux-
> > > mips-2.6/arch/mips/onstor/tuxstor/Makefile#1 edit
> > > ... //depot/tuxrx/linux/kernel/linux-
> > > mips-2.6/arch/mips/onstor/tuxstor/cm-api.c#1 add
> > > ... //depot/tuxrx/linux/kernel/linux-mips-2.6/include/linux/onstor/sm-
> > > chassis/cm-state-api.h#1 add
> > > ... //depot/tuxrx/linux/kernel/linux-mips-2.6/kernel/panic.c#2
> > > edit ... //depot/tuxrx/nfx-tree/code/sm-bsd-
> > > snmpd/agent/mibgroup/mibII/system_mib.c#2 edit
> > > ... //depot/tuxrx/nfx-tree/code/sm-chassis/Makefile#3 edit
> > > ... //depot/tuxrx/nfx-tree/code/sm-chassis/chassis-strings.c#1
> > > edit ... //depot/tuxrx/nfx-tree/code/sm-chassis/chassis-ui.c#4
> > > edit ... //depot/tuxrx/nfx-tree/code/sm-chassis/chassisd-bc.c#5
> > > delete ... //depot/tuxrx/nfx-tree/code/sm-chassis/chassisd-cg.c#4
> > > edit ... //depot/tuxrx/nfx-tree/code/sm-chassis/chassisd-msg.c#4
> > > edit ... //depot/tuxrx/nfx-tree/code/sm-chassis/chassisd.c#4 edit
> > > ... //depot/tuxrx/nfx-tree/code/sm-chassis/cm-api-bc.h#1 delete
> > > ... //depot/tuxrx/nfx-tree/code/sm-chassis/cm-api-cg.h#1 edit
> > > ... //depot/tuxrx/nfx-tree/code/sm-chassis/cm-api.c#2 delete
> > > ... //depot/tuxrx/nfx-tree/code/sm-chassis/cm-api.h#4 edit
> > > ... //depot/tuxrx/nfx-tree/code/sm-chassis/cm-bmfpga.c#3 delete
> > > ... //depot/tuxrx/nfx-tree/code/sm-chassis/cm-init.c#3 delete
> > > ... //depot/tuxrx/nfx-tree/code/sm-chassis/cm-intr.c#1 delete
> > > ... //depot/tuxrx/nfx-tree/code/sm-chassis/cm-linux.c#1 edit
> > > ... //depot/tuxrx/nfx-tree/code/sm-chassis/cm-msg.c#3 delete
> > > ... //depot/tuxrx/nfx-tree/code/sm-chassis/cm-openbsd.c#1 delete
> > > ... //depot/tuxrx/nfx-tree/code/sm-chassis/cm-tux.c#1 add
> > > ... //depot/tuxrx/nfx-tree/code/sm-chassis/cm-ui.c#3 delete
> > > ... //depot/tuxrx/nfx-tree/code/sm-chassis/cm-vars.c#1 delete
> > > ... //depot/tuxrx/nfx-tree/code/sm-chassis/cm.h#3 edit
> > > ... //depot/tuxrx/nfx-tree/code/sm-chassis/openbsd.h#1 delete
> > > ... //depot/tuxrx/nfx-tree/code/sm-ea/ea-util.c#3 edit
> > > ... //depot/tuxrx/nfx-tree/code/sm-utils/chassis-utils.c#1 edit
> > > ... //depot/tuxrx/nfx-tree/code/sm-utils/sys-utils.c#4 edit
> > > ... //depot/tuxrx/nfx-tree/code/ssc-cluster/clusdb-upgrade-common.c#4
> > > edit
> > > ... //depot/tuxrx/nfx-tree/code/ssc-ndmp/ndmp-config.c#4 edit
> > > ... //depot/tuxrx/nfx-tree/code/ssc-ndmp/ndmp-main.c#5 edit
> > > ... //depot/tuxrx/nfx-tree/code/ssc-nfxsh/cmd_flash.c#3 edit
> > > ... //depot/tuxrx/nfx-tree/code/ssc-nfxsh/cmd_system.c#6 edit
> > > ... //depot/tuxrx/nfx-tree/code/ssc-nfxsh/cmd_upgrade.c#3 edit
> > > ... //depot/tuxrx/nfx-tree/code/ssc-vtm/vtm-msg.c#5 edit
> > 
> > 
> > 
> > = Change 34392 by rendellf@rendellf-test on 2010/02/04 18:41:02
> > *pending* = 
> > = 	Clean up of chassis mgr code by removing obsolete Bobcat
> > and Cheetah = 	ifdef'd cases.  Removed unneeded references
> > to chassis mgr header files = 	in other various files.
> > Added new card type for Cougar platform and = 	cpu state
> > mgmt api routines.  Deleted txrx/fp chassis code since it has =
> > 	been replaced by user app code "cm".  Replaced use of
> > sendAgile messages = 	with rmc. = 
> > 
> > linux/kernel/linux-mips-2.6/arch/mips/onstor/tuxstor/Makefile
> > 
> >      should this not be a general driver, rather than in the
> > platform code?
> ok, moved it to drivers/mgmt-bus directory.
> > 
> > linux/kernel/linux-mips-2.6/arch/mips/onstor/tuxstor/cm-api.c
> > 
> >      >>add
> >      >>linux/kernel/linux-mips-2.6/arch/mips/onstor/tuxstor/cm-api.c
> > 
> >      line 4, please put your name in here as part of the copyright
> >      attribution.  you don't have to put your email address if you
> >      don't want to ~:^)
> > 
> Does it really matter?  This code will never be released will it?

Pro forma.  It will only be released if we make >1000 decisions based
on the assumption that it won't be released.  Not to mention that code
never dies.  It just gets cut-n-pasted to somewhere else.

> >      line 27 for kernel files like this, the comment convention
> > is /*
> >       * comment
> >        */
> >      Actually I think that's the "official" convention for Onstor
> >      as well.
> > 
> ok
> 
> >      line 30, lower case, please.  no study caps.  see line above
> > this one if you have questions ~:^)
> >
> ok
> 
> >      line 60 you're mixing uint32 style types with u64 style types
> >      right next to each other.  that's OK I guess, but I thought I
> >      would point it out just in case it wasn't what you intended.
> > 
> changed kernel types to onstor style types.
> 
> >      line 65 broken.  doesn't check if cpu is < 0, and upper bound
> >      is NFX_NFP_NUM_CPUS-1
> cpu is defined as unsigned which uint32 is last I checked.  How can it
> be less than 0?  Upper bound check looks ok to me.

If it is always positive, it should be a signed.  For example, what if
cpu==-1 means something to some code?


> > 
> >      line 66 improper printk.  many other places too.  should be
> >      printk(LEVEL "fmt")
> > 
> ok, added.
> 
> >      line 71 (and others) usually the %u conversion is used when %x
> >      should be used.  would it make more sense reading the output if
> >      these were displayed as hex numbers?  also, the error message
> >      should say why it can't, since the code does know why ~:^)
> > 
> ok, changed to hex. reworded error msg.
> 
> >      line 102 super ugly.  left hand cast and everything.  also,
> >      either the code should be obvious what's going on, or a comment
> >      explaining would be nice.
> > 
> Removed the cast.  Isn't it obvious that its setting a bitmapped bit
> in the mailbox reg based on the cpu state?  The routine description
> covers it.  Should I duplicate the same comments inline with the code?

I looked at it and I wasn't positive what it does.  What if we gave
this code to Usha tomorrow?  Never forget the little people, I never
say.

> 
> > 
> > 
> >      OK, having said all this, I now start to realize what you're
> >      trying to do with this, but this isn't going to work on
> > tuxstor. Individual cores aren't relevant, and don't crash or stuff.
> >      A thread might crash, but there wouldn't be anything to do in
> > the hardware when that happens, at least, not at the mailbox level.
> >      Let's talk about the purpose of this software and what the
> > design should be for tuxstor.
> > 
> There needs to be a single state, but I'm not changing the code to do
> that at this point.  It needs to be functionally consistent with
> Cougar so that I can test the vsvr changes later on.  Unless the cpu
> state transitions to the runtime state, the ssc apps will proceed on
> and init the system.  Changing the number of cpus would impact lots
> of other code including several cli cmds.
> 
> Right now, my plan is for the module init of big tux module set state
> of all cpus to runtime.  The ssc apps will detect this an continue
> starting up the system.
> 
> If you don't think I ought to check in this code, then so be it.
> I use it for my own testing.

We have to write code that makes sense, don't we?  If you want to check
it in, and then immediately redesign and fix it, well, I would say you
can try and sell that to the group on Monday and see what everyone else
thinks.  But it has to be fixed and I don't see why now is not the
time.  It can't pretend that we are running EEE in all instances, that
will confuse the heck out of people and programs.

I understand what you're feeling.  Would it be so bad to take one more
day, figure out a quick design, write a short blurb, email it around
to me, max, brian?  Maybe even Rich LaR or Sandrine, as this is
something they look at a lot, like the output of "system show chassis".


> > linux/kernel/linux-mips-2.6/include/linux/onstor/sm-chassis/cm-state-api.h
> > 
> >      >>add
> >      linux/kernel/linux-mips-2.6/include/linux/onstor/sm-chassis/cm-state-api.h
> > 
> >      line 35 hws (hidden or covered white space) after macro name
> > 
> ok
> 
> > linux/kernel/linux-mips-2.6/kernel/panic.c
> > 
> >      might need some changes based on comments in previous file
> > 
> > nfx-tree/code/sm-bsd-snmpd/agent/mibgroup/mibII/system_mib.c
> > 
> >      looks good
> > 
> > nfx-tree/code/sm-chassis/Makefile
> > 
> >      looks good
> > 
> > nfx-tree/code/sm-chassis/chassis-strings.c
> > 
> >      line 1, I hate these at the top of a file.  prettier to put
> > them at the bottom.
> > 
> >      I doubt most of these card types and whatnot will be here in
> > the end version of this.  But you probably figured that out already
> >      after my other comment.
> > 
> removed old card types.

cool, thanks


> > nfx-tree/code/sm-chassis/chassis-ui.c
> > 
> >      line 33 there should be no sm-libc/ usage.  clean up as
> > necessary to fix that.  i think.
> > 
> ok

mucho thanks.

> >      line 309, i think this is bad RMC code.  oops, that's
> > redundant. check with max on proper RMC api, if you haven't
> > already.  i think max once told me good rmc code has either
> > rmc_client_init or rmc_server_init in it, but not rmc_open.
> > 
> I'll have Max review it.  I don't want to use the new api because more
> code would have to be re-arranged.  The new api is not well suited for
> synchronous processing of responses.

good idea

> >      line 500 cleanup this if 0 crap too.  if it's debug code, then
> >      change this to if DEBUG or something.
> > 
> >      line 789 reboot_slot has no meaning in tuxstor
> > 
> removed.
> 
> > 
> > nfx-tree/code/sm-chassis/chassisd-bc.c
> > 
> >      >>delete nfx-tree/code/sm-chassis/chassisd-bc.c
> > 
> >      good
> > 
> > 
> > nfx-tree/code/sm-chassis/chassisd-cg.c
> > 
> >      line 1, move to bottom
> > 
> >      line 1201, unless this polls between SSC and "tuxstor" it
> > doesn't have much meaning
> > 
> 
> I don't understand what the problem is.  Do you want the name changed?
> I haven't touched it.  chassisd uses this routine to monitor tuxstor
> status.

there is no routine for each core that monitors anything.  let's say
some code in the tuxstor kernel calls panic().  does that
code path just blithely go through a hardware specific array, setting
each to element to CRASHED?  wouldn't that be pretty silly in light of
how tuxstor *is* versus how EEE is?  maybe keep this paradigm but only
have one cpu or something.

> > 
> > 
> > nfx-tree/code/sm-chassis/chassisd-msg.c
> > 
> >      line 1, move to bottom
> > 
> >      damn, i might be wrong, but i think most of this might be
> > redundant code.  as I said before in a previous comment, this is
> > probably all taken care of by the RMC API of new.  Check with Oprah.
> >      Oops, I mean Max.
> > 
> I'll have Max review it.

okay

> > 
> > nfx-tree/code/sm-chassis/chassisd.c
> > 
> >      looks good
> > 
> > nfx-tree/code/sm-chassis/cm-api-bc.h
> > 
> >      >>delete nfx-tree/code/sm-chassis/cm-api-bc.h
> > 
> >      ok
> > 
> > nfx-tree/code/sm-chassis/cm-api-cg.h
> > 
> >      line 1, ditto
> > 
> > 
> > 
> > nfx-tree/code/sm-chassis/cm-api.c
> > 
> >      >>delete nfx-tree/code/sm-chassis/cm-api.c
> > 
> >      ok
> > 
> > nfx-tree/code/sm-chassis/cm-api.h
> > 
> >      line 35 uh, i thought we were getting rid of this cruft?
> >      many changes implied in this code for tuxstor.
> 
> ok, I'll remove the bobcat/cheetah/fcnim cases.
> 
> > 
> > 
> > nfx-tree/code/sm-chassis/cm-bmfpga.c
> > 
> >      >>delete nfx-tree/code/sm-chassis/cm-bmfpga.c
> > 
> >      ok
> > 
> > nfx-tree/code/sm-chassis/cm-init.c
> > 
> >      >>delete nfx-tree/code/sm-chassis/cm-init.c
> > 
> >      ok
> > 
> > nfx-tree/code/sm-chassis/cm-intr.c
> > 
> >      >>delete nfx-tree/code/sm-chassis/cm-intr.c
> > 
> >      ok
> > 
> > 
> > nfx-tree/code/sm-chassis/cm-linux.c
> > 
> >      looks good
> > 
> > nfx-tree/code/sm-chassis/cm-msg.c
> > 
> >      >>delete nfx-tree/code/sm-chassis/cm-msg.c
> > 
> >      ok
> > 
> > nfx-tree/code/sm-chassis/cm-openbsd.c
> > 
> >      >>delete nfx-tree/code/sm-chassis/cm-openbsd.c
> > 
> >      ok
> > 
> > nfx-tree/code/sm-chassis/cm-tux.c
> > 
> >      >>add nfx-tree/code/sm-chassis/cm-tux.c
> > 
> >      line 1, the usual
> > 
> >      lines 21-24, 28-9, i know some of the morons around here can't
> > get it through their heads, but header files not below the directory
> >      where this C file resides should be in <>.  i'm just sayin'.
> > 
> >      line 49,145,151,356, tws
>
> ok

yeesh, now that i reread this, i realize you might think I meant you,
but i was refering to max and larry.  those morons.  you and i are
entirely different morons.

> > 
> >      line 182, if this needs fixing, put a common searchable string
> >      in front of it line '@@@' or whatever
> 
> It will be removed now that I've got the version string.

ah

> > 
> >      line 277 do we *have* to have studly caps?
> > 
> This is an existing routine name. I didn't create it.

ok

> >      line 392, really?  why not?  then it shouldn't be compiled in
> > or called anywhere?
> Defined separate sig handler for both chassisd and cm.

uuh.  i don't remember the specifics now.  so you're saying it does
something in chassisd but not in cm, or vice-versa?


> > nfx-tree/code/sm-chassis/cm-ui.c
> > 
> >      >>delete nfx-tree/code/sm-chassis/cm-ui.c
> > 
> >      ok
> > 
> > nfx-tree/code/sm-chassis/cm-vars.c
> > 
> >      >>delete nfx-tree/code/sm-chassis/cm-vars.c
> > 
> >      ok
> > 
> > nfx-tree/code/sm-chassis/cm.h
> > 
> >      line 111-113 some studly caps, some not.  hmmm.
> > 
> Those are the existing routine names. I didn't create them.

ok

> > 
> > nfx-tree/code/sm-chassis/openbsd.h
> > 
> >      >>delete nfx-tree/code/sm-chassis/openbsd.h
> > 
> >      yeah!
> > 
> > 
> > nfx-tree/code/sm-ea/ea-util.c
> > 
> >      looks good
> > 
> > nfx-tree/code/sm-utils/chassis-utils.c
> > 
> >      looks good
> > 
> > nfx-tree/code/sm-utils/sys-utils.c
> > 
> >      looks good
> > 
> > nfx-tree/code/ssc-cluster/clusdb-upgrade-common.c
> > 
> >      looks good
> > 
> > nfx-tree/code/ssc-ndmp/ndmp-config.c
> > 
> >      looks good
> > 
> > nfx-tree/code/ssc-ndmp/ndmp-main.c
> > 
> >      looks good
> > 
> > nfx-tree/code/ssc-nfxsh/cmd_flash.c
> > 
> >      looks good
> > 
> > nfx-tree/code/ssc-nfxsh/cmd_system.c
> > 
> >      looks good
> > 
> > nfx-tree/code/ssc-nfxsh/cmd_upgrade.c
> > 
> >      looks good
> > 
> > nfx-tree/code/ssc-vtm/vtm-msg.c
> > 
> >      looks good

