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	14824	861DA0537719934884B3D30A2666FECC010E1E82C6@cosmail02.lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Thu, 25 Feb 2010 13:46:46 -0800
From: Andrew Sharp <andy.sharp@lsi.com>
To: "Kozlovsky, Maxim" <Maxim.Kozlovsky@lsi.com>
Subject: Re: Please review
Message-ID: <20100225134646.1409dac7@ripper.onstor.net>
In-Reply-To: <861DA0537719934884B3D30A2666FECC010E1E82C6@cosmail02.lsi.com>
References: <861DA0537719934884B3D30A2666FECC010E178D8C@cosmail02.lsi.com>
 <20100223115407.0d1029c8@ripper.onstor.net>
 <861DA0537719934884B3D30A2666FECC010E1E82C6@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

On Tue, 23 Feb 2010 14:25:15 -0700 "Kozlovsky, Maxim"
<Maxim.Kozlovsky@lsi.com> wrote:

> Also please review
> 
> ... //depot/tuxrx/linux/kernel/linux-mips-2.6/net/neteee2/eee-timer.c#5
> edit
> 
> Need to disable this caller right away.
> 
> -----Original Message-----
> From: Kozlovsky, Maxim 
> Sent: Tuesday, February 23, 2010 1:21 PM
> To: Sharp, Andy
> Subject: RE: Please review
> 
> = Change 34672 by maximk@maximk-13 on 2010/02/23 10:40:54 *pending*
> = 
> = 	Create FP polling threads in eee init function.
> = 	       Add sleep/wakeup mechanism to polling loop, the
> polling thread = 	       will go to sleep if the loop did not
> process any events. = 	       Add module exit function.
> = 	       Reviewed by andys.
> = 
> 
> 
> My biggest concern is that there are design changes represented by
> some of this code.  Not big changes necessarily, but ones which a
> wider audience should know about?  I'm specifically thinking about
> Bill. [MK] This was discussed already and is described in the design
> document.

ok

> 
> linux/kernel/linux-mips-2.6/drivers/mgmt-bus/rcon.c
> 
>      looks good
> 
> linux/kernel/linux-mips-2.6/include/linux/onstor/sm-eee/eee-poll.h
> 
>      line 47 bool?  in the kernel?  it's a violation against man
>      and nature.  I prefer to stick to non-imaginary data types in the
>      kernel as much as possible.  More about this farther down.
> [MK] Nothing wrong with bool, kernel code uses it, try searching in
> the tree.

Yes, there are others in the kernel, but that doesn't mean they belong
there or are good examples of kernel programming.  We'll chat about
boolean sometime soon.

> 
> 
> linux/kernel/linux-mips-2.6/include/linux/onstor/sm-eee/eee.h
> 
>      ok
> 
> 
> linux/kernel/linux-mips-2.6/net/neteee2/eee-init.c
> 
>      line 94 why test eee.eee_threads[i] for NULL?  If it can be NULL,
>      then possibly this is racy and should be protected by a lock?
> [MK] It will be NULL if the initialization fails on an earlier member
> of the array. There is no race.

If you say so.

>      line 208 just curious, what module is this?
> [MK] neteee2. No I did not name it.

I bet you wish you had.  It's an awesome name.

> linux/kernel/linux-mips-2.6/net/neteee2/eee-poll.c
> 
>      line 371 nice, except for the bool, which i know you will fix
> ~:^) [MK] No 

Next time bool or some other unnecessarily obfuscated data type bites
you in the ass, I'll be there to laugh.

>      line 439 seriously, why do we need two?  sed
>      s/eee_registerPollingFunc/eee_register_polling_func/
> [MK] We don't need two, but I am not fixing all the callers right
> away, so I am temporary redirecting. When all the callers are fixed
> I'll remove eee_registerPollingFunc().

Ok.

>      line 691 the userspace 'bool' type.  since you're
>      doing integer operations on it, let's make it an unsigned int
> LGI. [MK] Ok made it logical operation.

A logical operation?  Is there such a thing on truth values?  Why not
change the type to match the operation you want to do?  You can keep it
if you want.  As long as I can get rid of them if I want.

>      line 717 this looks like a good candidate for an inline
> [MK] It will be inlined anyway if the compiler thinks it is a good
> candidate. It is a good practice to never add inline to static
> routines in .c files because they might grow and stop being good
> inline candidates.

I was implying that it be moved to a .h.  I don't think the compiler
will inline it, because it's called from other modules, is it not?    I
mean, why else preserve it.  It's better practice not to obfuscate
behind what a compiler might do.   If it changes, then it might need to
be changed. That's true of every line of code.

>      line 737 sheesh, about time someone who knows how to write kernel
>      code got involved.  nice.  on orion, the I/O VM has a problem
>      right now: it uses 100% cpu all the time.  maybe we should loan
>      you to them.  naaah.  ~:^)


linux/kernel/linux-mips-2.6/net/neteee2/eee-timer.c

     line 287 should we combine these two ifdef 0/later sections?


