AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20070419093740.162d7a69@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<maxim.kozlovsky@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	0	BB375AF679D4A34E9CA8DFA650E2B04E0351BC45@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Thu, 19 Apr 2007 09:37:42 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Maxim Kozlovsky" <maxim.kozlovsky@onstor.com>
Subject: Re: Please review
Message-ID: <20070419093742.7843509d@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E0351BC45@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E032A6A27@onstor-exch02.onstor.net>
	<20070405141235.508a5be7@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E032A6A40@onstor-exch02.onstor.net>
	<20070418163503.24a3dab5@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E0351BA33@onstor-exch02.onstor.net>
	<20070418174503.23b0e555@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E0351BC45@onstor-exch02.onstor.net>
Organization: Onstor
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

OK, you're the man with the list.

a


On Thu, 19 Apr 2007 08:54:50 -0700 "Maxim Kozlovsky"
<maxim.kozlovsky@onstor.com> wrote:

> This is not an exception.
> 
> If they don't belong, get rid of them all together, and fix any code
> as necessary. this isn't just an exercise in porting code but a time
> to clean things up.  The best thing is to axe this include file, and
> see what code stops compiling.  Probably very little?
> 
> Alternatively, you could just have these files be in the include list
> only on BSD makes.  That's probably the least effort method.
> 
> I thought you wrote all this code?  ~:^)  But seriously, this is
> pretty messed up.
> [MK] 
> Not all this code. Anyway, I moved it to a different directory.
> 
> 
> Well then, are you keeping a list of things you're definitely going to
> go back and fix?  BTW, it's not harder than I think.  If it was easy,
> we would have given the job to Jon.
> 
> Are you saying it was originally inline?  Again, this is our big
> opportunity to make things better.  It's only a few key strokes, and
> we all know how fast you type.
> [MK] 
> I do and it is just too messed up to fix together with other things.
> Take a look at code/sm-event/emrs-api.h. 
> 
> >      in which the list of files to compile is defined.  so if linux
> > has one or two more or one or two less source files, the respective
> >      list of source files would be defined in the included makefile,
> >      like linux.mk, openbsd.mk, etc.
> > MK> I don't think building a library with an empty list of files
> > MK> works.
> 
> hmm.  i don't get it.  why would it be empty?
> [MK] Because fgetln is in standard library for bsd and the bsd
> compatibility library for bsd has empty contents.
> 
> > nfx-tree/code/ssc-bsdcompat/openbsd.h
> > 
> >      ditto for this essentially empty file as well
> > MK> Seems to be necessary, otherwise you'll get an error on missing
> > include file when doing '#include OS_INCL'
> 
> hmm
> 
> > nfx-tree/code/ssc-nfxnis/nfxdns-openbsd.c
> > 
> >      line 729 is whitespace, and looks like a bug to me.  and why
> > one should
> >      always use curly braces, even for one line.
> > 
> > MK> Right. Go tell this to BSD guys. Doesn't look like a bug, just
> > messed up indentation.
> 
> but you're the BSD guy.  isn't this our code?
> [MK] Not anymore. And this is not our code. It was copy/pasted from
> the BSD resolver library and hacked a little bit. Somehow it lost the
> copyright notice in the process.
> 
> 
> > nfx-tree/code/ssc-nfxnis/openbsd/resolv-internal.h
> > 
> >      err, empty file?  no-no.  unless it will eventually get stuff
> > in it.
> > MK> What's the problem with empty files? I can put a copyright
> > MK> notice
> > there, this will make it non-empty.
> 
> the answer to this question is not immediately coming to mind.  i just
> know we shouldn't have any.  any ideas?
> 
> 
> [MK] Nothing comes to mind right away. 
> 
> MK> Some is, but it will require additional effort to separate it.
> > Starting from the assumption that none is portable is safe.
> 
> throw it on the list.  what is vserver-ipm anyway?
> [MK] 
> Something that messes with the kernel to create/delete network
> interfaces when the virtual servers are enabled/disabled.
> 
