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	1268275337.16781.605.camel@rendellf
X-Sylpheed-End-Special-Headers: 1
Date: Thu, 11 Mar 2010 11:10:32 -0800
From: Andrew Sharp <andy.sharp@lsi.com>
To: Rendell Fong <Rendell.Fong@lsi.com>
Subject: Re: please review - 34392
Message-ID: <20100311111032.65387adf@ripper.onstor.net>
In-Reply-To: <1268275337.16781.605.camel@rendellf>
References: <1268165053.16781.463.camel@rendellf>
	<20100310105856.439da579@ripper.onstor.net>
	<1268262525.16781.529.camel@rendellf>
	<20100310160142.03342b73@ripper.onstor.net>
	<1268275337.16781.605.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 19:42:17 -0700 Rendell Fong <Rendell.Fong@lsi.com>
wrote:

> On Wed, 2010-03-10 at 17:01 -0700, Andrew Sharp wrote:
> > 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.
> >
> So which file header should I be using as a template?  I've seen so
> many different formats.  Is the standard file header documented in
> the coding standards somewhere?  Please give me the pointer to it.

You're making it harder than it needs to be.

> > > >      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?
> >
> The valid range of cpus is from 0 to 5, inclusive.
> See the NFX_NFP_* defines in nfx-defs.h.
> No need to use a signed value.  If it's out of range it's invalid,
> plain and simple.  Using a signed value means that you have to check
> both upper and lower bounds and is not as efficient as treating it as
> unsigned.  None of the callers of this routine should be setting cpu
> to any value that's out of range.  It just doesn't make any sense.

OK, so you're going to trot out the "it doesn't make sense argument"?
Well, now that you put it that way, you're obviously right, so leave it.

However, what also doesn't make sense is {reporting on, and, having all
this infrastructore code for} 6 cpus for tuxstor.  Yes, I know it will
take an effort to fix that, and some actual thinking, maybe not much
though, to think through how to rework it, and to rework it.  And?
Do you have something better to do?  If you want to finish the vsvr
stuff first and then go back, of course, by all means.  If you want to
do 5 other things first, and then go back, of course, by all means.
But some time it needs to be done.  I just figured since you're on it
now, no time like the present.

Anything depending on Bill getting his changelists in is likely going
to be hurting indeed.


> > > >      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.
> >
> I don't know what more could be said. Certain states are common to all
> cpus and bitmapped.  One bit is assigned to each cpu for the runtime
> state.  This is the existing code and I haven't changed it.
> 
> > >
> > > >
> > > >
> > > >      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'm in no rush to check it.  I've now got what I need to do the vsvr
> testing once Bill gets his changes in.  Speaking of EEE, what about
> its slot/cpu addressing scheme.  When will that be changed?
> Shouldn't it be changed simultaneously.

I don't know the answer to the first part, but this and that are not
dependent on each other.

> Personally, I'd rather do several incremental changes rather than one
> big change. But that's just me.

I don't care how you want to do it.  Knock yourself out.

> > 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".
> >
> If you are talking about changing just the output for system show
> chassis|version commands. Then that is simple to do.  But changing the
> number of cpus in nfx-defs.h is more risky and impacts mucho code.  I
> don't have a handle on what will break.  PROM code will be affected as
> well.

I'm not talking about trivially changing the output.

PROM code was changed a long time ago.  Yes, it's true: all the code
affected will have to be changed.  I was never ignorant of that fact.
There might be 10, even 20 files affected. Could even be 40.

> > > > 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?
> Yes, to keep chassis code on the ssc side happy.
> The way it works is that the state progresses from PROM_INIT, to
> RUNTIME_INIT, to RUNTIME.  The prom code sets the state to PROM_INIT
> and the runtime code sets the state to the other 2 when the kernel and
> kernel modules are loaded.
> 
> Then if a crash occurs, the state progresses from CRASHED, to
> CRASH_DONE or RESET_WAIT depending on the autoreboot flag.  Note that
> these states are always numerically higher in value.  chassisd
> monitors the states and posts cpu events (UP/DOWN) accordingly. The
> tuxstor kernel doesn't need to do any monitoring of cpu state.
> Hence, there is no overhead for the tuxstor side when things are
> running as normal.
> 
> If a watchdog timeout occurs, the state would revert to PROM_INIT.
> chassisd would detect this change and eventually reboot the whole
> system.
> 
> > wouldn't that be pretty silly in light of
> > how tuxstor *is* versus how EEE is?
> No, eee addresses still operate in terms of slot/cpu.  It maps to cpu
> Id numbers that the chassis code deal with.
> 
> > maybe keep this paradigm but only
> > have one cpu or something.
> >
> Yes, that's the thought.  If we change things to handle one cpu now,
> more code will be affected and be part of this change.  This includes
> prom code as well.
> 
> > > >
> > > >
> > > > 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?
> >
> 
> So chassisd and cm now have their own sigTerm handlers.
> chassisd needs to disable the watchdog while cm doesn't.
> 
> >
> > > > 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
> >
> 
