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>,<Maxim.Kozlovsky@lsi.com>,<Bill.Fisher@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/LSI/INBOX	0	1265062126.24463.242.camel@rendellf
X-Sylpheed-End-Special-Headers: 1
Date: Mon, 1 Feb 2010 15:07:57 -0800
From: Andrew Sharp <andy.sharp@lsi.com>
To: Rendell Fong <Rendell.Fong@lsi.com>
Cc: "Kozlovsky, Maxim" <Maxim.Kozlovsky@lsi.com>, "Fisher, Bill"
 <Bill.Fisher@lsi.com>
Subject: Re: elog()
Message-ID: <20100201150757.074ace0f@ripper.onstor.net>
In-Reply-To: <1265062126.24463.242.camel@rendellf>
References: <861DA0537719934884B3D30A2666FECC010DFDEB92@cosmail02.lsi.com>
	<20100129165205.52bea929@ripper.onstor.net>
	<1265043936.24463.204.camel@rendellf>
	<861DA0537719934884B3D30A2666FECC010DFDEDC4@cosmail02.lsi.com>
	<1265057401.24463.235.camel@rendellf>
	<861DA0537719934884B3D30A2666FECC010DFDEEB9@cosmail02.lsi.com>
	<1265062126.24463.242.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 Mon, 1 Feb 2010 15:08:46 -0700 Rendell Fong <Rendell.Fong@lsi.com>
wrote:

> On Mon, 2010-02-01 at 14:42 -0700, Kozlovsky, Maxim wrote:
> > 
> > -----Original Message-----
> > From: Rendell Fong [mailto:Rendell.Fong@lsi.com] 
> > Sent: Monday, February 01, 2010 12:50 PM
> > To: Kozlovsky, Maxim
> > Cc: Sharp, Andy
> > Subject: RE: elog()
> > 
> > On Mon, 2010-02-01 at 11:43 -0700, Kozlovsky, Maxim wrote:
> > > Hello,
> > > 
> > > I just have to ask, why are we moving the code? Anything wrong
> > > with the previous location? The process seems to be kind of
> > > random, some code moves, some does not, what algorithm are you
> > > using to decide to move stuff? 
> > > 
> > 
> > The elog code is tentatively being moved so that elogs can be posted
> > before the module is loaded.  If that is not the case, then the code
> > doesn't need to be moved and I'll just forget about this change.
> > [MK] I did not quite get this, elogs can't be posted until elog
> > module is loaded... How that can be otherwise?
> > 
> 
> We have a separate elog module?  I didn't know that you defined it
> explicitly.

No, we don't have an elog module.  It was part of the
big/main/networking/The-kernel-module/whatever at one time.

Yes, we will have stuff that is not in a module and is therefore "in
the kernel."  We already do, including, but not limited to, our
platform code, mgmtbus driver, rmc apparently....

That said, I have no objection to everything being a module.

> > > Some comments on the code itself below.
> > > 
> > > Max
> > > 
> > > You should use p4 integrate instead of p4 add to preserve the
> > > history. You did not merge the dev branch changes to the files.
> > > This is what happens when you start moving things.
> > > 
> > I'll do it based on what your response is above.
> > 
> > > 
> > > Acpu.c:
> > > 
> > > 51: E_log_init() should be module initialization function instead
> > > of being called from acpu thread initialization function
> > > 
> > 
> > I planned on the elog code being in the kernel.  If it ought to be
> > in the module instead, then obviously e_log_init should be in the
> > module init function.
> > [MK] 
> > All our code should be in module(s), there should be no kernel
> > changes. Elog cannot be part of the kernel.

I presume you meant "shouldn't be part of the kernel" because surely it
could be.


> > > 357, 401: cast is redundant
> > 
> > Not really, but I'll change it anyway since you insist.  
> > kmalloc returns a (void *) and the variables aren't (void *).
> > [MK] void * does not need to be cast, this is why it was added to
> > the language.
> > 
> > > 225: this function is called during initialization in the current
> > > code, don't see where this is done in yours.
> > > 
> > That's because the elog config called in main module init code.
> > The main module init is in a separate change list.
> > [MK] There is no such thing as "main" module as far as I know. 
> > 
> > 
> > > You removed e_log_var_pa() but the code still uses it.
> > 
> > No its not.  Only SSC case uses it.
> > [MK] 
> > You are mistaken, check again, code/sm-fs/fs-proto.h
> > 
> > > 
> > > Elog-api.h:
> > > 
> > > 188: You changed how the macro behaves, it used to check if the
> > > logging needs to be done at all before doing the function call
> > > for the performance reasons. The comment right above the macro,
> > > which was not changed to conform to the new code, mentions it.
> > 
> > > 
> > 
> > The check has been moved from the macro to e_log prior to var list
> > alloc processing.  I'll update the comments.
> > [MK] Why not leave the code as it was before? Clearly there were
> > some reasons to do it this way, why do you think there is no
> > performance impact from doing this change?
> > 
> 
> Fine.  I'll leave the code as is and let you handle it.

What changes are we talking about here?  Can folks be specific?


> > > 
> > > 
> > > -----Original Message-----
> > > From: Rendell Fong [mailto:Rendell.Fong@lsi.com] 
> > > Sent: Monday, February 01, 2010 9:06 AM
> > > To: Sharp, Andy
> > > Cc: Kozlovsky, Maxim
> > > Subject: Re: elog()
> > > 
> > > I have a change list (34033) that will add elog in.  It is 1 of
> > > my 4 change lists waiting on Bill's changes to get submitted
> > > first.
> > > 
> > > 
> > > On Fri, 2010-01-29 at 17:52 -0700, Andrew Sharp wrote:
> > > > On Fri, 29 Jan 2010 17:31:07 -0700 "Kozlovsky, Maxim"
> > > > <Maxim.Kozlovsky@lsi.com> wrote:
> > > > 
> > > > > Did you define this function anywhere? I can't seem to find
> > > > > it.
> > > > 
> > > > Ask Rendell, I think he took care of that.  It's got to be
> > > > *somewhere*, which is what customers say about our log data....
> > > 
> > 
> 
