[openib-general] [PATCH] use mmiowb after doorbell ring

[Michael S. Tsirkin]

Quoting r. Roland Dreier <rdreier at cisco.com>:
> Subject: Re: [PATCH] use mmiowb after doorbell ring
> 
>  > > > Hopefully that is under prefix:
>  > > > $prefix/etc/libibverbs.conf.d/
>  > > 
>  > > Well, $sysconfdir/libibverbs.conf.d
>  > 
>  > Ugh, is that a problem if I want to build and run as non-root?
>  > I'm used to be able to set --prefix on config line for all libs
>  > to some directory, put LD_LIBRARY_PATH to point there, then
>  > if I like I just blow all of it away and I get a clean system.
>  > Scattering config files around in home directory etc will break this.
> 
> I'm not following the objection: what's wrong with using $sysconfdir?
> It defaults to $prefix/etc like you want, and it can be overridden
> with the --sysconfdir parameter to configure.

Sorry, looks like I was confused.

>  > > > Finally, it might be nice to be able to just specify the list of
>  > > > plugins at configure time for people like me who buuild everything
>  > > > from source and who want less flexibility
>  > > > but also less files to install.
>  > > 
>  > > Again, is that really any easier
>  > 
>  > Well, I'm thinking of distributed systems mainly where copying extra
>  > files around is additional pain.
>  > Consider myself: I'm building things on my laptop, then pushing them out to
>  > machines in the lab over rsync for testing. Less files - less headache.
>  > 
>  > > than putting whatever you want into
>  > > your .libibverbs.conf?
>  > 
>  > I really don't think a library sticking things in user's home directory
>  > is such a great idea - typical users don't really know they link against
>  > some library, this is just an extra place that users can break:
>  > move to another machine, things stop working, and your app's
>  > manual does not say anything of course.
> 
> libraries don't stick anything in home directories -- I'm just
> suggesting $HOME/.libibverbs.conf as a place to stick extra configs
> that users might want to add.
> 
> I'm kind of thinking that we might want other config options beyond
> just driver names someday.  Otherwise we might as well have
> /etc/libibverbs.drivers.d and an environment variable IBV_DRIVERS, I
> guess.  But it might be nice to be able to add a line like
> 
>     default-fork-safe true
> 
> somewhere in libibverbs.conf.d to set a system-wide default.

I see. Looks somewhat useful - do you really intend something like this?
Then we'd need an API for app to set fork support state explicitly -
we currently only make it possible to enable it, not to disable.

> I dunno what's better.  Maybe separate environment variables for
> user-specific configs are just as good -- eg that's what ld.so does.

Hmm.
I guess what I'm trying to say is - let's follow some precedent.
ld.so example is good. Are there others?

>  > 
>  > > I definitely plan to make it so a missing plug-in is not fatal, so it
>  > > shouldn't hurt to have extra drivers declared that you don't build
>  > > every time.
>  > 
>  > Not until someone decides to rename a plugin for some reason - then you
>  > have to hunt down and kill the old file name to prevent an old version
>  > stuck in library path for some reason from being loaded - easy with the
>  > central location, but good luck walking all user's home directories.
> 
> Hmm, this seems to argue against allowing environment variables or
> anything but a single directory built into libibverbs.  Because
> otherwise you have to grep every .bashrc .cshrc and so on.

Hmm, good point.
I like it that with environment I can just pass it on command line and
not worry about any files which might be left behind.

-- 
MST