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:<Bill.Fisher@lsi.com>,<Brian.Stark@lsi.com>,<Rendell.Fong@lsi.com>,<Larry.Scheer@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/LSI/INBOX	0	4B511672.70002@lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Fri, 15 Jan 2010 19:08:39 -0800
From: Andrew Sharp <andy.sharp@lsi.com>
To: "Fisher, Bill" <Bill.Fisher@lsi.com>
Cc: "Stark, Brian" <Brian.Stark@lsi.com>, "Fong, Rendell"
 <Rendell.Fong@lsi.com>, "Scheer, Larry" <Larry.Scheer@lsi.com>
Subject: Re: tuxrx Branch Change List 34077 review requested
Message-ID: <20100115190839.589784f3@ripper.onstor.net>
In-Reply-To: <4B511672.70002@lsi.com>
References: <4B4FDE26.50003@lsi.com>
	<20100115155046.35fd87f2@ripper.onstor.net>
	<4B511672.70002@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 Fri, 15 Jan 2010 18:29:22 -0700 William Fisher <bill.fisher@lsi.com>
wrote:

> Andrew Sharp wrote:
> > Just to be clear, it doesn't go in without at least these two
> > reviews: one from me and one from Rendell.  Rendell because of the
> > vsvr integration questions and possible userspace building
> > questions, and me to try and stem the chaos that has plagued things
> > recently.  Apart from deletes, I didn't see any makefile changes,
> > so probably not much for Larry to look at.
> > 
> 
> 	There is one change to Makefile.acpu to change the order
> 	and to remove the typealoosa.h directive. This file
> 	has move to be called nfx-types-extra.h and contains
> 	most of what was there with a few edits.
> 
> 	The "chaos", what are you referring to?
> 
> 	Rendell's changes will
> 	replace nearly all of the sm-vsvr directory and most of the
> 	vs statistics code, that he is changing to get the results.
> 
> 	We should have created a common set of header files over
> 	a year ago, but that is water over the dam, let's just
> 	get this thing on the road.

That's the chaos.  I'm taking the blame and the responsibility.

> 	I talked with Larry about the SSC daemons. One suggestion
> 	is to do this in steps rather than one huge change list.

Fine by me, let's hear the sketch of the plan on Monday.

> 	These are separable problems and don't need to be
> 	joined together.

> > Bill, can you attempt to discuss with Max whatever his concern is?
> > I say 'attempt' for obvious reasons.  You mentioned the vsvr
> > pointer to me many times ... I'd be shocked if you hadn't mentioned
> > it to Max at least once.  Just in case anybody cares, my stance is,
> > as always: if that's what needs doing, then that's what needs
> > doing.  Anyway, I thought in the comments you said it was moved,
> > not deleted.
> > 
> 
> 	Why didn't you add Max to the cc line? I told him about

If I send Max and email, he will lock his mind, dig in his heels, and
refuse to listen to anybody ever again on the subject.  Trust me, I
know.

> 	this change quite some time ago. The goal was to
> 	avoid pulling all of the VS header files into nearly
> 	everything in the system. This code suffer's from
> 	header file layering and basic information hiding
> 	normally associated with very large software projects.

Right, so I know what's going on and the change doesn't surprise me.
Maybe Max forgot what you told him, I don't know.

> 	It is late to be adding this now, however it should
> 	help going forward for maintaining the code and
> 	separating internal definitions from externally
> 	visible API one's.
> 
> 	I have NO energy on the virtual server pointer change,
> 	this is what Rendell suggested so I implemented it.
> 	I think Rendell's gets the call since it is his
> 	VS implementation NOT Max's.
> 
> 	Jonathon and I talked about this topic last week
> 	since the VS object will be the heart of all
> 	file access'es from the network for naming,
> 	statistics and other VS specific changes.
> 	He was concerned about the numa awareness
> 	for a future scale out problem.
> 
> 	If Max's only complaint is the vs_p pointer that
> 	is amazing. That is like pointing out that a
> 	cigarette butt is in the ashtray of a very
> 	expensive used car, not exactly a show stopper.

It didn't strike me as even that rational, but since he doesn't
explain why he thinks it shouldn't be changed, so what do I know.

> -- Bill
