AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20070419131946.592d299c@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<tim.gardner@onstor.com>,<larry.scheer@onstor.com>,<maxim.kozlovsky@onstor.com>,<dl-Cougar@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	BB375AF679D4A34E9CA8DFA650E2B04E0351BE79@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Thu, 19 Apr 2007 13:20:01 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Tim Gardner" <tim.gardner@onstor.com>
Cc: "Larry Scheer" <larry.scheer@onstor.com>, "Maxim Kozlovsky"
 <maxim.kozlovsky@onstor.com>, "dl-Cougar" <dl-Cougar@onstor.com>
Subject: Re: linux ssc changes
Message-ID: <20070419132001.7c6e4036@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E0351BE79@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E02215747@onstor-exch02.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E0351BE79@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

I don't know if max is claiming that is *has* to be part of
usr/include, but this is not a controversy.  I've stated that we aren't
going to modify system include files with our changes like we did with
OpenBSD, that was wrong [and sick].

The neteee defines will be part of a kernel include file, which will
probably be installed into usr/include/linux, or usr/include/asm*, under
the cross-build directory, just like other kernel headers.  I don't see
any reason to mess with that formula.

Cheers,

a

On Thu, 19 Apr 2007 13:12:43 -0700 "Tim Gardner"
<tim.gardner@onstor.com> wrote:

> I agree. Max, could you elaborate on any reasons that neteee has to be
> in /usr/include.
> Is it because we are adding a protocol family to one of the standard
> OS include files?
> 
> _____________________________________________
> From: Larry Scheer 
> Sent: Thursday, April 19, 2007 11:58 AM
> To: Maxim Kozlovsky; dl-Cougar
> Subject: RE: linux ssc changes
> 
> I don't agree that our neteee directory should be part
> of /usr/include. /usr/include should contain OS code and not ONStor
> proprietary code. It should be in a logical place. Perhaps
> nfx-tree/Includes is where it belongs? 
> 
> Larry
> 
> _____________________________________________
> From: Maxim Kozlovsky 
> Sent: Thursday, April 19, 2007 11:37 AM
> To: dl-Cougar
> Subject: linux ssc changes
> 
> I have checked in some changes that allow most of the ssc modules to
> compile and link. Here is the list of the things that needs to be done
> next:
> 
> 1)	The neteee directory should be part of
> compiler /usr/include. Currently only compile2 has it there.
> 2)	 The ldap library needs to be updated with our changes.
> Compile2 has the updated library, but there is no place to check it
> in currently. If you want to install it on your system, it is build in
> ~maximk/libldap-src.
> 3)	The modules starting from ssc-sshd-kb5 in the ssc Makefile
> do not compile. Here is the complete list:
> 				ssc-sshd-kb5 \
> 				samba-3.21a \
> 				sendmail \
> 				ssc-socat \
> 				sm-bsd-snmpd \
> 				ssc-webui
> 4)	In some of our code for SSC the authors took a shortcut and
> defined huge functions inline in include files instead of creating a
> library as a normal person would do. Since we are changing all this
> code anyway we should fix this, here is the list of directories (grep
> for "inline" for file list)
> 		Sm-event
> 		Ssc-nfxnis
> 		Includes/linux
> 		Includes/openbsd
> 5)	Start implementing the pieces missing for linux. The
> directories in this list will have a file with *linux* in the name
> and corresponding *openbsd* file. In the end the *linux* file should
> implement the same functionality as the *openbsd* file.
> 	./sm-chassis/
> 	./sm-event/
> 	./sm-ipmd/
> 	./sm-opt/f
> 	./sm-sct/
> 	./ssc-cluster
> 	./ssc-crashsave
> 	./ssc-nfxnis
> 	./ssc-nfxsh
> 	./ssc-pm
> 	./ssc-vsd
> 
> 6)	Look through the source for calls to "system", "execve" and
> similar functions. The compiler can not warn about non-portable things
> in this code, so it has to be done by inspection.
