[Openib-windows] Branding

[Fab Tillier]

> From: Yossi Leybovich [mailto:sleybo at mellanox.co.il]
> Sent: Wednesday, October 19, 2005 11:02 AM
> 
> > From: Fab Tillier [mailto:ftillier at silverstorm.com]
> > Sent: Wednesday, October 19, 2005 7:47 PM
> >
> > Right now since the SVN trunk is under "gen1", the major
> > version number is 1. The minor number is zero just because we
> > have to start somewhere.  We can define a process by which
> > major and minor version numbers are changed, but this can
> > wait until we need it.
>
> One more little thing don't you think it better to put the SVN version var in
> last number (VER_FILEREV(

If you look at Windows binaries, they use the 3rd field in the version number to
indicate the build number.  I was just going to use the SVN revision as the
build number, but we could use monotonically increasing build numbers instead
and put the SVN number in the VER_FILEREV field.  I'm open to suggestions here.
In fact, the VER_FILEREV field could be used to indicate the OpenIB version, and
the VER_FILEBUILD the company specific build number.  This might be a good way
to give information about what SVN version a vendor specific build is based on.

> > Ok.  I want us all to be very careful that we don't apply a
> > patch and create a vendor release and then stop putting
> > pressure to apply that patch (or its
> > equivalent) to the trunk.  This applies to both patches and
> > features added to the core.
> 
> That the state that we in Mellanox standing now. We need the IPoIB patch and
> the CR MAP patch
> We need them for our release and they still did not come in to the OpenIB.

It's hard to prioritize the IPoIB patch to support SDP which isn't in SVN yet
when there are bugs to be fixed in the code that's already out there.  It's also
hard for me to justify spending cycles on applying a patch that doesn't have any
immediate benefit to me or the OpenIB community since we don't have access to
the code that uses it.  When can we expect SDP to show up in a branch in SVN?

For the configuration space mappings, the patch hasn't been applied because it
is broken.  Proper cleanup needs to be part of it.  I don' think we should make
a habit of committing half baked patches just to get functionality out there.
Currently, if the application that has the CR space mapped crashes, you will
leak kernel resources.  Worse yet is that you expect user-mode to hand you a
kernel pointer for the MDL to release, and perform no checking of that provided
pointer.  You cannot ever trust user-mode to give you valid kernel pointers.
Even if not malicious, a bug in the application could corrupt its stored value
of the pointer and inadvertently cause a system crash when trying to cleanup.

- Fab