[ofa-general] Re: Location and naming of RDMA stack enablement rpm

[Doug Ledford]

Roland Dreier wrote:
>  > Right now, in the OFED packaging, there are extra files added to the
>  > overall stack that aren't currently part of any base RPM.  I'm mainly
>  > talking about things like the /etc/udev.d/rules/90-ib.rules,
>  > /etc/init.d/openibd, etc.  These files belong to none of the upstream
>  > rpms, yet they (or administrator hand edited equivalents) are required
>  > for the stack to work well.
>  > 
>  > Since both prior to the IB/iWARP merge and after, libibverbs is
>  > required for most functionality to operate at all, I would propose
>  > that those basic startup files be included in the libibverbs rpm.
> 
> That doesn't make sense to me.  For example, the udev rules really
> belong in whatever distro package supplies the rest of the udev rules.

The upstream udev maintainer is tired of trying to maintain a list of 
all the right rules.  He wants people that need rules to supply their 
own files under the /etc/udev/rules.d directory.

> Similarly, it doesn't make sense to me to have a startup script in
> libibverbs, since libibverbs has nothing to do with what's being
> started.

Well, yes and no.  The standard startup script fires up the kernel verbs 
modules (as well as others).  But, I can see the point.

> There are a couple of reasons why I feel this way.  First, it's
> completely sane to have a system that only runs an SM, or SDP/libsdp,
> or something like that -- and in that case there's no reason to
> install libibverbs at all.  Second, I don't want to maintain unrelated
> distribution-specific stuff in libibverbs just because it's a
> convenient dumping ground.
>

Fair enough.

> My solution would be to create a package to hold all the miscellaneous
> stuff, maybe something like openfabrics-base-support, and then make
> the other packages depend on that so it gets installed when it needs to.

I can agree with that.

>  > So, on top of proposing that these items go into libibverbs, I'd like
>  > to request that we reach a consensus on what name to use in /etc for
>  > consolidating these config files and put all the reasonably related
>  > config files in that directory.  For example, the dat.conf should go
>  > in there, as well as opensm.conf, libsdp.conf, and openibd.conf.
>  > However, I would not recommend placing the various mpi config files
>  > under there as these are fully functional, stand alone applications
>  > that can run with or without the RDMA stack underneath it.
>  > 
>  > That being said, I'll say that my preference for the name of the
>  > directory is /etc/ofa.  I prefer ofa over ofed because eventually this
>  > stack should be buildable package by package without doing a big
>  > conglomerate build of everything.  In fact, I'm currently going
>  > through git repos and making changes to the head of each repo to
>  > enable the packages to be built easily by themselves via rpm spec file
>  > rules. Under that sort of build environment, ofed is misleading while
>  > ofa is accurate.
> 
> I think it makes sense to get rid of the name /etc/ofed.  I would
> suggest /etc/openfabrics instead of /etc/ofa, since it's more
> self-explanatory -- if I see /etc/ofa it's not instantly obvious who's
> responsible for it.

Well, another option I didn't mention in my previous mail is to do away 
with group specific naming and go with functionality specific naming, 
aka /etc/rdma since it's all rdma related.  Kind like how /etc/sendmail 
went to /etc/mail.

> I'll add as a note that these issues seem to come from the continuing
> confusion between a "release" and a "distribution", and that things
> would be a lot clearer if there were an upstream openfabrics release
> that both OFED, Red Hat, etc could package according to their own needs.
> (Although the /etc/ directory name should be decided outside of the
> distributions so that there's some uniformity)

Agree 100%.  Part of the changes I submitted to Hal for review included 
a simple make.dist script that automates the process of checking for a 
unique release number, tagging the git repo with the release number, and 
parsing the spec.in file into a final version suitable for rebuild with 
just rpmbuild --ta tarball, then packs it all up into the tarball, ready 
to be downloaded.

-- 
Doug Ledford <dledford at redhat.com>
http://people.redhat.com/dledford

Infiniband specific RPMs can be found at
http://people.redhat.com/dledford/Infiniband