Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo

[Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 4816 bytes --]

On 8/29/2016 2:29 AM, Leon Romanovsky wrote:
> On Sun, Aug 28, 2016 at 12:36:27PM -0600, Jason Gunthorpe wrote:

> I'm doing that by running number of one liners [1], it builds me
> development setup in shared folder, so my base image is continuing
> to be clean.
> 
> It is not final version, I didn't upload it yet.
> 
> Libraries:
> 	@echo "Build libibverbs"
> 	@cd $(LIBIBVERBS_SRC)/; ./autogen.sh; ./configure --prefix=$(KVM_SHARED) CFLAGS=-I$(KVM_SHARED)/include LDFLAGS=-L$(KVM_SHARED)/lib CPPFLAGS=-I$(KVM_SHARED)/include; $(MAKE); $(MAKE) install
> 	@echo "Build libmlx5"
> 	@cd $(LIBMLX5_SRC)/; ./autogen.sh; ./configure --prefix=$(KVM_SHARED) CFLAGS=-I$(KVM_SHARED)/include LDFLAGS=-L$(KVM_SHARED)/lib CPPFLAGS=-I$(KVM_SHARED)/include; $(MAKE); $(MAKE) install

So, with the changes Jason is proposing, nothing in the above changes
drastically except you can skip all of the "make install" commands
between builds of things like libibverbs and libmlx5 and the libmlx5
build will still be built against the right code, all the time.  This is
an improvement in the process from what it is today.  Regardless of
distro issues.  It's just an improvement period.

>> Doug is also adressing a larger issue with packaging and getting
>> everything to build correctly as the distro - he talked about it here:
>>
>> https://www.spinics.net/lists/linux-rdma/msg37855.html
> 
> I read that thread and think that it is related to unoptimized build
> process of one distro who for any reason decided do not use repo tool
> [2]

I'm pretty sure the repo tool didn't exist when Red Hat created their
build process.

> for managing complex build dependencies between different git trees,

We do this on a regular basis.  It actually isn't hard for almost
anything besides the RDMA stack.

> but used excel file and manual download of source tarballs.

Just to be clear, *I* used a spreadsheet in tracking my work, that's not
part of the standard workflow inside Red Hat.  But when you have a
deadline looming, and 30+ packages to build, and a complex web of
interrelated dependencies, and an overloaded build system because
everyone else is building packages too, it just helps to avoid mistakes
and blown builds if you track your work accurately.

As for source tarballs, this is because when rpm was invented (back in
1994 or so), that's all there was.  That was the standard.  An argument
could be made that rpm should be updated to work with git repos.  I've
made that argument myself, and in some ways it has.  But the gold
standard is still source tarballs.  Every project has them, they are
easy to verify, and they are constant.  According to Fedora's packagedb,
Fedora now has upwards of 20,000 different source packages in total.
Many of these use alternate SCMs, like mercurial, subversion, there
might even be a few still on crusty old CVS.  So tarballs are still the
only universal you can get from every project.

> We used such tool for our 100+ git trees project and it worked like a charm.
> There is worth to invest time and revise internal process of releasing
> RDMA stack in that specific distro and no need to invent new beast
> (rdma-plumbers).

Unfortunataely, what you speak of is not really realistic, both for the
reasons I've cited and a whole litany of other reasons I didn't mention.

But I don't think Jason jumped in to work on this because of the goal of
making Red Hat's life easier in packaging up the separate code.  He did
it for upstream related reasons:

1) Put all of the providers and libibverbs in one place so that they can
be kept in sync.  This allows us to do the exact same thing we do with
the kernel in user space.  Namely, if someone makes an incompatible
change in the libibverbs core, we can require that they fix up all
providers in the same patch series.  This works rather well for the
kernel, and it would be good to bring that policy to user space too.

2) Put all of the kernel interacting libraries in one place.  This makes
it easier to perform the write->ioctl conversion we've been discussing
as there would be only one larger package that needs to be updated for
any given kernel ioctl update.

3) Bring librdmacm and libibverbs together so that the occasional
incompatible update between the two is not an issue any more.

4) Create an easier to build/install package for developers to use.

Those are the issues we should be discussing the relative merits of in
order to determine whether this work should be adopted.

> [1] https://github.com/rleon/dev-scripts/blob/master/Makefile#L89
> [2] https://source.android.com/source/developing.html
> 
>>
>> Jason


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG Key ID: 0E572FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]