Quoting r. Roland Dreier <[EMAIL PROTECTED]>: > 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 _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
