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:<Maxim.Kozlovsky@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/LSI/INBOX	0	861DA0537719934884B3D30A2666FECC010DFDE777@cosmail02.lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Thu, 28 Jan 2010 15:14:01 -0800
From: Andrew Sharp <andy.sharp@lsi.com>
To: "Kozlovsky, Maxim" <Maxim.Kozlovsky@lsi.com>
Subject: Re: review of changelist 33991
Message-ID: <20100128151401.7635af76@ripper.onstor.net>
In-Reply-To: <861DA0537719934884B3D30A2666FECC010DFDE777@cosmail02.lsi.com>
References: <20100127171026.4f1226c2@ripper.onstor.net>
	<861DA0537719934884B3D30A2666FECC010DFDE621@cosmail02.lsi.com>
	<20100128142407.5f307a45@ripper.onstor.net>
	<861DA0537719934884B3D30A2666FECC010DFDE777@cosmail02.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

I did indeed have to deal with deeper directories, look at the unicode
stuff.

But as you said, none of this is reason hold up the changelist.

Thanks,

a


On Thu, 28 Jan 2010 15:39:19 -0700 "Kozlovsky, Maxim"
<Maxim.Kozlovsky@lsi.com> wrote:

> > nfx-tree/Includes/nfx-target.h
> > 
> >      i'm sorry, but we have two macros, one is SBM_REV2 and one is
> >      SBM_REV_2?  now is the time to fix that
> > [MK] No it is not the time 
> 
> Yes, please, now is the time.  I cannot understand what's going on
> with these macros and the inconsistent use of them.
> [MK] Need to draw the line somewhere, I can't fix any little thing
> that catches the eye. The way to fix the inconsistent defines is to
> remove them completely, since the code does not make sense without
> them defined, but this will be completely unrelated change. Making
> them consistent first and then removing later is a waste of time.
> 
> > 
> > nfx-tree/code/neteee2/eee-timer-api.c
> > 
> >      line 634, we don't use this silliness any more.  rtczero is
> > just 0. [MK] Apparently not, otherwise this will not be necessary.
> 
> It isn't necessary, that's my point.  I've removed it from all the
> places it was used in the txrx side of things.
> [MK] Well this is not the right way of doing things, you should have
> removed it from everywhere or not remove it at all. The code
> elsewhere still uses this function so it needs to be defined until
> that code is changed. This is an issue for a separate change if it
> really needs solving.
> 
> > 
> >      this definitely doesn't look right to me.  i realize that
> >      there might be some makefiles that have this dual mode, that
> >      will be going away since we won't be doing a separate tuxrx
> >      and tuxfp projects.  also, this will build the sm-fs directory
> >      as a separate kernel module, which i doubt is what you want.
> >      the rules for the generated code should be like real makefile
> >      rules, not just a list of identical rules, one for each file.
> > [MK] This file is used to compile user space and kernel hence the
> > dual mode.
> 
> Userspace compiles in sm-fs?
> [MK] Yeah, imagine that. fsdb is compiled out of sm-fs directory.
> 
> > 
> > nfx-tree/code/sm-fs/restore/restore.c
> > 
> >      line 39, this is silly.  please adopt the use of the <>.
> > [MK] That's how everything is included and <> will not help here.
> > Apparently the make file rules you produced are not quite right so
> > that including that file in some other way does not work.
> 
> It does work, I used it extensively to solve this exact problem.
> [MK] <> is the same as "" as far as looking up the file in the
> include paths, if "" does not work changing it to <> will not make it
> work. Anyway, as long as the right file gets included, this is hardly
> a matter worth arguing about.
> 
> 
> > nfx-tree/code/sm-fs/restore/seccache-api.h
> > 
> >      line 30 this is actually wrong, since the path inside "" is
> >      relative to the file the does the including, not the header
> > file. switch to the <> syntax please.  especially for header files.
> >      you won't have to mess with this stuff ever again.
> > [MK] You are mistaken
> 
> Hardly.  But have it your way.  Of course, if you look, I never had to
> add or delete any "../" to anything.
> [MK] You did not have to deal with deeper directories.
> 
>  
> > nfx-tree/code/sm-ispfc/ispfc.c
> > 
> >      line 115 please use the standard kernel methods for reading
> >      registers (io.h)
> > [MK] Why bother this code is going away anyway.
> 
> The ispfc code isn't going anywhere?  There's nothing to replace it in
> the kernel that I know of.
> [MK] It will be temporary until x86 port is done, there will not be
> any ispfc code there. 
> 
> > nfx-tree/linux.mk
> > 
> >      no, this is only done for ssc build
> > [MK] PROD=tx is how ssc is compiled.
> 
> Damn.  I'll chat with you about this in person.
