X-Sylpheed-Account-Id:2
S:andy.sharp@lsi.com
SCF:#mh/Mailbox/sent
X-Sylpheed-Sign:0
X-Sylpheed-Encrypt:0
X-Sylpheed-Privacy-System:
RMID:#imap/LSI/INBOX	0	4AE24B70.5010008@lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Fri, 23 Oct 2009 19:42:54 -0700
From: Andrew Sharp <andy.sharp@lsi.com>
To: William Fisher <bill.fisher@lsi.com>
Cc: "Fong, Rendell" <Rendell.Fong@lsi.com>, "Scheer, Larry"
 <Larry.Scheer@lsi.com>, "Stark, Brian" <Brian.Stark@lsi.com>, "Fisher,
 Bill" <Bill.Fisher@lsi.com>
Subject: Re: please review 33334
Message-ID: <20091023194254.578cc8cc@ripper.onstor.net>
References: <20091022172108.51f46b80@ripper.onstor.net>
	<4AE24B70.5010008@lsi.com>
Organization: LSI
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hello Mr. Drama,

We'll sit down and discuss what changes you would like to see me make,
but it general it isn't your place to tell me what is and isn't a good
use of my time.  I spend my goodly amount of time at work doing actual
work, and unless you can demonstrate the same or superior, you shouldn't
be casting aspersions lest a spotlight is shown on your productivity.

The mgmtbus work was done back in jan, feb or something like that.  And
yes, it's a big improvement, a lot cleaner, and in the vein of how
portable code is supposed to be done here.  All it is is reorganizing
for maintainability.  Perhaps you find such code craftsmanship a bit
intimidating.  Your remarks would certainly indicate that.  And try to
keep in mind that it's not your personal code, so you shouldn't take it
personally when it gets changed.  You criticize Max for doing just
that, remember?

As for the renaming to tuxstor, let me also catch you up on a
little recent history: the tuxrx project and name *has* been replaced by tuxstor.  We'll send you a memo.

It's quite necessary to maintain a level of clarity.  Tuxrx doesn't
exist and having some old, temporary project name in there is not good
at all and leads to considerable confusion.  I was the one who did all
the work originally to create the tuxrx version of the platform code and
configs, so it falls to me to update it.  Again, try to to get so
intimidated: there's a reason why I'm heading this project.

Perhaps this is more about your desire, but apparent lack of ability,
to break up the eee kernel code into multiple modules and directories,
which isn't on the schedule in any way either.


On Fri, 23 Oct 2009 18:33:52 -0600 William Fisher <bill.fisher@lsi.com>
wrote:

> Andrew Sharp wrote:
> > Hi guys,
> > 
> > Larry need only look at the makefile changes.
> > 
> > The tuxstor build doesn't quite work because I need to follow up
> > this changelist with another one to fix the TUXRX references the
> > newly created tuxstor files.
> > 
> > Change 33334 by andys@ripper on 2009/09/14 17:48:04 *pending*
> > 
> > 	Changes for switching to new tuxstor project from old tuxrx
> > 	project.
> > 
> > 	Minor cleanup of linux/Makefile and linux/kernel/Makefile.
> > 
> > 	Add external symbol declarations for small number of symbols
> > 	needed by the acpu module.
> > 
> > 	Clean up comments and some of the macros in mgmtbus driver
> > code, plus reorganize some of the code to eliminate large ifdef
> > blocks and other infelicities.  Bring the recent changes to the code
> > 	in the dev tree over as well.
> > 
> > 	Move linux/kernel/linux-mips-2.6/arch/mips/onstor/tuxrx
> > 	to ...tuxstor.
> > 
> > 	Micro cleanup of the mgmtbus-aware code in sb1250-mac.c
> > (sibyte ethernet driver).
> > 
> > 	reviewed by
> > 
> > Affected files ...
> > 
> > ... //depot/tuxrx/linux/Makefile#1 edit
> > ... //depot/tuxrx/linux/kernel/Makefile#2 edit
> > ... //depot/tuxrx/linux/kernel/linux-mips-2.6/.git/logs/HEAD#1 edit
> > ... //depot/tuxrx/linux/kernel/linux-mips-2.6/.git/logs/refs/heads/onstor-2.6.22#1
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/arch/mips/Kconfig#3
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/arch/mips/Makefile#3
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/arch/mips/kernel/head.S#2
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/arch/mips/kernel/stacktrace.c#1
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/arch/mips/onstor/Kconfig#3
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/arch/mips/onstor/common/ons_crashdump.c#2
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/arch/mips/onstor/tuxrx/dbg_io.c#1
> > delete ... //depot/tuxrx/linux/kernel/linux-mips-2.6/arch/mips/onstor/tuxrx/setup.c#1
> > delete ... //depot/tuxrx/linux/kernel/linux-mips-2.6/arch/mips/onstor/tuxstor/Makefile#1
> > branch ... //depot/tuxrx/linux/kernel/linux-mips-2.6/arch/mips/onstor/tuxstor/dbg_io.c#1
> > branch ... //depot/tuxrx/linux/kernel/linux-mips-2.6/arch/mips/onstor/tuxstor/prom.c#1
> > branch ... //depot/tuxrx/linux/kernel/linux-mips-2.6/arch/mips/onstor/tuxstor/setup.c#1
> > branch ... //depot/tuxrx/linux/kernel/linux-mips-2.6/arch/mips/onstor/tuxstor/time.c#1
> > branch ... //depot/tuxrx/linux/kernel/linux-mips-2.6/arch/mips/pci/Makefile#2
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/arch/mips/pci/fixup-tuxrx.c#1
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/arch/mips/pci/fixup-tuxstor.c#1
> > add ... //depot/tuxrx/linux/kernel/linux-mips-2.6/cougar-config#4
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/cougar-debug-config#3
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/drivers/mgmt-bus/Kconfig#1
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/drivers/mgmt-bus/Makefile#1
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/drivers/mgmt-bus/cougar_mgmt_bus.c#1
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/drivers/mgmt-bus/mgmt-bus.c#1
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/drivers/mgmt-bus/mgmt-bus.h#1
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/drivers/mgmt-bus/rcon.c#1
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/drivers/mgmt-bus/rcon.h#1
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/drivers/mgmt-bus/tuxrx_mgmt_bus.c#1
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/drivers/net/sb1250-mac.c#2
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/include/asm-mips/bootinfo.h#2
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/include/asm-mips/mach-tuxstor/cpu-feature-overrides.h#1
> > branch ... //depot/tuxrx/linux/kernel/linux-mips-2.6/include/asm-mips/mach-tuxstor/tuxstor.h#1
> > branch ... //depot/tuxrx/linux/kernel/linux-mips-2.6/include/linux/onstor/ons_crashdump.h#1
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/include/linux/slab_def.h#1
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/include/net/sock.h#3
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/kernel/stacktrace.c#1
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/kernel/time.c#1
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/kernel/time/timekeeping.c#1
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/net/Kconfig#3
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/net/Makefile#3
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/net/neteee/neteee.c#2
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/net/onstor/Kconfig#1
> > delete ... //depot/tuxrx/linux/kernel/linux-mips-2.6/net/onstor/Makefile#1
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/net/onstor/acpu.c#2
> > edit ... //depot/tuxrx/linux/kernel/linux-mips-2.6/tuxrx-config#2
> > delete ... //depot/tuxrx/linux/kernel/linux-mips-2.6/tuxrx-debug-config#2
> > delete ... //depot/tuxrx/linux/kernel/linux-mips-2.6/tuxstor-config#1
> > branch ... //depot/tuxrx/linux/kernel/linux-mips-2.6/tuxstor-debug-config#1
> > branch ... //depot/tuxrx/nfx-tree/Makefile.tuxstor#3 edit
> > 
> 
> I have gone through about 60% of the files.

Go through the rest, if only for your own edification.

> I can't believe that you have spent so much time reworking
> the comment layout in the header files, doing useless
> renaming of ONSTOR_TUXRX to ONSTOR_TUXSTOR in the Kconfig
> for virtually no purpose except to satifsy your belief
> that the TXRX name should now be TUXSTOR!

You don't know how much time I've spent, so why are you characterizing
it so?  Actually, I think it's pretty obvious.  Really, I didn't mean to
intimidate you with all the coding that I'm able to do in a short time.

> This is completely wasted effort particularly since
> we are behind schedule and this adds NO new features
> to get us moving forward.

Get back to me when you've added as many new features as I have.

> You have stripped off the /* CONFIG_XXX */ lines
> off the #endif's statements for some reason and
> you are inconsistent with those changes throughout
> the code. Some places you have ripped them
> off and others they escaped your edits.

I've done nothing of the sort.

> You have now made the mgmt_bus.h header file now nearly unreadable
> IMHO. You have added huge amount of white space for no particularly
> good reason, by stripping off comments at the end of lines
> and added new lines containing the comments. What for?
> Editorial perspective?

I've restored it to it's original format from the borken format I found
it in.  If you are done failing to try to make yourself look
superior, just tell me what format you would like it in.

> The acpu.c file you now have ifdef'ed out the code that
> makes the current rcon-shell and polling loop to
> work by adding a "ifdef 0" comment with an
> additional comment, "To be resolved later".
> 
> Thanks, that just means I have to revert the file to
> add them back until the rcon shell is made
> more modular, until then we are broken if this
> change goes in.
> 
> Obviously you have not run any of the rcon shell
> commands, the polling loop code nor any of the
> EEE packet forwarding tests on this code as
> all of them will be broken. How is that forward
> progesss?

Bill, when you're reviewing someone's changelist, you're not supposed to
try and show how amazingly smart you are while really showing what a
frightened little boy you are, you're supposed to be reviewing the code
change.  Tell me how it needs to be different and I will make it so; or
just tell me it is in need of fixing and I will do that.  If I
need to ask how to fix it, I'll waddle down to your cube and ask
you.  That's what one is supposed to do in a code review. You should
know that considering you're supposed to be a super-senior engineer
here.

> You have moved large chucks of the mgmtbus
> initialization code to a separate file
> since that is somehow "cleaner" than what
> was there, with an ifdef.

You're kinda yelling at yourself here, aren't you?  This is infinitely
cleaner, because it's called "portable" code, rather than hackerific
unreadable ifdefery, and therefore unmaintainable, code.  The exact
thing you've said over and over that is bad about the eee code.
Besides, I didn't spend much time on it back in January, I just tried to
clean up the major bits.  I still left some ugly ifdefs in there for
you to cling to.

> The half-life of this driver going forward
> will probably be short since x86 is on the
> horizon and all of the mgmtbus, rcon drivers
> and the cougar platform specific code is
> not going forward.

You need to work on keeping your arguments straight.

> I don't have the time to provide comments on
> all of the diff's
> on each of the times but 90+% of these
> changes are not needed NOR required.

Make the time, it's one of your responsiblities, just like every
developer.  I spent at least six hours reviewing your change list, and
will have to do so over and over until it's ready to be checked in.  So
stop whining about having to do your job.

> What specific bugs are these fixes addressing?

What these fixes, as you so rightly call them, are about, is
addressed in the checkin comments.

> Converting the ONSTOR_TUXRX to ONSTOR_TUXSTOR
> config variables is make-work. I can't believe
> you spent time editing those changes.

I think what's bothering you is that I do lots of work like this making
things better, in addition to big important changes, while you've had 8
months to do the networking code and it still isn't done.  How long
does your precious task list say the networking code should take?

> It should be LSI_XXX since ONSTOR no
> longer exists, if you want to be
> specific.

No, because it's not the company, it's the product.

> There are a few cleanups on the architecture
> specific portions of the driver code that are nice
> but not worth spending time on, right now.

The time has already been spent by me, and what's worth spending time
on, especially my time, is my decision.

> These changes are NOT even identified in the
> development schedule as something critical.
> The ones we called out were, getting a set
> of PROM for booting, now not needed, getting
> an 8-way kernel running, the remote 1480
> PCI device driver identification for the FC
> device, etc.

You need to get better in touch with what your place is, because it
doesn't include policing my task list.  Maybe it scares or bothers you
that policing your task list is part of my job, but that's no excuse.
Start to show me the proper respect or I'm going to kick you off this
project.

> The critical bug fix was the ETHERNET MAC
> address not being unique since we were not
> getting the correct bottoom bits.
> I found that bug weeks ago and Rendell did
> the fix several weeks ago.

Wrong, Rendell found the bug six months ago and I did the fix right
then and there.  You did nothing except fail.  You failed to
incorporate it into your tree when I sent it to you at that time.  And
you failed to include it in the code you buffuloed Rendell into
checking in for you.  So I took care of tracking it down and getting it
in, because that's my job.  I didn't say anything to anyone about your
failures.

Another critical bug fix, which you failed to mention or track into the
branch, was the mgmtbus reserved area bug fix that Rendell engineered,
which I ported over from the dev branch.

> Hence, in summary, the changes to the
> mgmtbus driver, rcon driver, trivial
> CONFIG variable renames and the acpu changes
> and wholesale changes to huge comment blocks
> are NOT required.

Absolutely required, and is what should have been checked in in the
first place by Rendell, except that his change, which was really your
change, went in without proper review.  So in fact, this is partly
about fixing that error, while making the code more maintainable.

> This change set should be cut down by at least 85%
> by removing those changes. The gratuious changes
> to the comments and endif's are another
> set of changes that reduce readability IMHO,
> when you have nested ifdef's in the code.

No need to remove anything that's already been done.  That would just
be adding more time to the time you claim was a waste, while throwing
away much improved code.  Code you should study in order to improve
your own skills.

> This change set needs rework.

While I'm sure it needs a few changes, which is why it's sent out for
review, rework is what your changelist needs, and I think you are
merely projecting from a place of trepidation.

Cheers,

a
