| Message ID | 1431440068-19037-1-git-send-email-jsquyres@cisco.com (mailing list archive) |
|---|---|
| State | Accepted |
| Delegated to: | Doug Ledford |
| Headers | show |
Doug -- The feedback on this patch seems to have converged. What's the process for getting this accepted into libibverbs (and rolling a new libibverbs release)? > On May 12, 2015, at 10:14 AM, Jeff Squyres (jsquyres) <jsquyres@cisco.com> wrote: > > It's not a warning or an error if libibverbs cannot find a userspace > driver for kernel devices. Indeed, returning a num_devices of is > sufficient -- the middleware shouldn't be unconditionally printing out > stderr message; let the upper layer application do that (if it wants > to). > > For debugging purposes, if the environment variable IBV_SHOW_WARNINGS > is set (to any value), warnings will be emitted to stderr if a > corresponding userspace driver cannot be found for a kernel device. > > Signed-off-by: Jeff Squyres <jsquyres@cisco.com> > --- > man/ibv_get_device_list.3 | 6 ++++++ > src/init.c | 2 +- > 2 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/man/ibv_get_device_list.3 b/man/ibv_get_device_list.3 > index 16cc1a0..96de554 100644 > --- a/man/ibv_get_device_list.3 > +++ b/man/ibv_get_device_list.3 > @@ -50,6 +50,12 @@ Client code should open all the devices it intends to use with > Once it frees the array with > .B ibv_free_device_list()\fR, > it will be able to use only the open devices; pointers to unopened devices will no longer be valid. > +.P > +Setting the environment variable > +.BR IBV_SHOW_WARNINGS > +will cause warnings to be emitted to stderr if a kernel verbs device > +is discovered, but no corresponding userspace driver can be found for > +it. > .SH "SEE ALSO" > .BR ibv_fork_init (3), > .BR ibv_get_device_name (3), > diff --git a/src/init.c b/src/init.c > index d0e4b1c..dbdd795 100644 > --- a/src/init.c > +++ b/src/init.c > @@ -561,7 +561,7 @@ out: > next_dev = sysfs_dev ? sysfs_dev->next : NULL; > sysfs_dev; > sysfs_dev = next_dev, next_dev = sysfs_dev ? sysfs_dev->next : NULL) { > - if (!sysfs_dev->have_driver) { > + if (!sysfs_dev->have_driver && getenv("IBV_SHOW_WARNINGS")) { > fprintf(stderr, PFX "Warning: no userspace device-specific " > "driver found for %s\n", sysfs_dev->sysfs_path); > if (statically_linked) > -- > 2.2.1 >
Hi Jeff, Le mardi 19 mai 2015 à 14:11 +0000, Jeff Squyres (jsquyres) a écrit : > Doug -- > > The feedback on this patch seems to have converged. What's the > process for getting this accepted into libibverbs (and rolling a new > libibverbs release)? > > Is Doug the maintainer of the userspace library ? > > On May 12, 2015, at 10:14 AM, Jeff Squyres (jsquyres) < > > jsquyres@cisco.com> wrote: > > > > It's not a warning or an error if libibverbs cannot find a > > userspace > > driver for kernel devices. Indeed, returning a num_devices of is > > sufficient -- the middleware shouldn't be unconditionally printing > > out > > stderr message; let the upper layer application do that (if it > > wants > > to). > > > > For debugging purposes, if the environment variable > > IBV_SHOW_WARNINGS > > is set (to any value), warnings will be emitted to stderr if a > > corresponding userspace driver cannot be found for a kernel device. > > > > Signed-off-by: Jeff Squyres <jsquyres@cisco.com> > > --- > > man/ibv_get_device_list.3 | 6 ++++++ > > src/init.c | 2 +- > > 2 files changed, 7 insertions(+), 1 deletion(-) > > > > diff --git a/man/ibv_get_device_list.3 b/man/ibv_get_device_list.3 > > index 16cc1a0..96de554 100644 > > --- a/man/ibv_get_device_list.3 > > +++ b/man/ibv_get_device_list.3 > > @@ -50,6 +50,12 @@ Client code should open all the devices it > > intends to use with > > Once it frees the array with > > .B ibv_free_device_list()\fR, > > it will be able to use only the open devices; pointers to unopened > > devices will no longer be valid. > > +.P > > +Setting the environment variable > > +.BR IBV_SHOW_WARNINGS > > +will cause warnings to be emitted to stderr if a kernel verbs > > device > > +is discovered, but no corresponding userspace driver can be found > > for > > +it. > > .SH "SEE ALSO" > > .BR ibv_fork_init (3), > > .BR ibv_get_device_name (3), > > diff --git a/src/init.c b/src/init.c > > index d0e4b1c..dbdd795 100644 > > --- a/src/init.c > > +++ b/src/init.c > > @@ -561,7 +561,7 @@ out: > > next_dev = sysfs_dev ? sysfs_dev->next : > > NULL; > > sysfs_dev; > > sysfs_dev = next_dev, next_dev = sysfs_dev ? > > sysfs_dev->next : NULL) { > > - if (!sysfs_dev->have_driver) { > > + if (!sysfs_dev->have_driver && > > getenv("IBV_SHOW_WARNINGS")) { > > fprintf(stderr, PFX "Warning: no userspace > > device-specific " > > "driver found for %s\n", sysfs_dev > > ->sysfs_path); > > if (statically_linked) > > -- > > 2.2.1 > > > >
On Tue, 2015-05-19 at 16:14 +0200, Yann Droneaud wrote: > Hi Jeff, > > Le mardi 19 mai 2015 à 14:11 +0000, Jeff Squyres (jsquyres) a écrit : > > Doug -- > > > > The feedback on this patch seems to have converged. What's the > > process for getting this accepted into libibverbs (and rolling a new > > libibverbs release)? > > > > > > Is Doug the maintainer of the userspace library ? Libibverbs and the kernel verbs interface are very closely tied, so I did ask Roland if he was OK with me taking over that as well. It would make it easier to keep the two in sync. Roland was fine with that. If anyone has any objections, please speak now. > > > > On May 12, 2015, at 10:14 AM, Jeff Squyres (jsquyres) < > > > jsquyres@cisco.com> wrote: > > > > > > It's not a warning or an error if libibverbs cannot find a > > > userspace > > > driver for kernel devices. Indeed, returning a num_devices of is > > > sufficient -- the middleware shouldn't be unconditionally printing > > > out > > > stderr message; let the upper layer application do that (if it > > > wants > > > to). > > > > > > For debugging purposes, if the environment variable > > > IBV_SHOW_WARNINGS > > > is set (to any value), warnings will be emitted to stderr if a > > > corresponding userspace driver cannot be found for a kernel device. > > > > > > Signed-off-by: Jeff Squyres <jsquyres@cisco.com> > > > --- > > > man/ibv_get_device_list.3 | 6 ++++++ > > > src/init.c | 2 +- > > > 2 files changed, 7 insertions(+), 1 deletion(-) > > > > > > diff --git a/man/ibv_get_device_list.3 b/man/ibv_get_device_list.3 > > > index 16cc1a0..96de554 100644 > > > --- a/man/ibv_get_device_list.3 > > > +++ b/man/ibv_get_device_list.3 > > > @@ -50,6 +50,12 @@ Client code should open all the devices it > > > intends to use with > > > Once it frees the array with > > > .B ibv_free_device_list()\fR, > > > it will be able to use only the open devices; pointers to unopened > > > devices will no longer be valid. > > > +.P > > > +Setting the environment variable > > > +.BR IBV_SHOW_WARNINGS > > > +will cause warnings to be emitted to stderr if a kernel verbs > > > device > > > +is discovered, but no corresponding userspace driver can be found > > > for > > > +it. > > > .SH "SEE ALSO" > > > .BR ibv_fork_init (3), > > > .BR ibv_get_device_name (3), > > > diff --git a/src/init.c b/src/init.c > > > index d0e4b1c..dbdd795 100644 > > > --- a/src/init.c > > > +++ b/src/init.c > > > @@ -561,7 +561,7 @@ out: > > > next_dev = sysfs_dev ? sysfs_dev->next : > > > NULL; > > > sysfs_dev; > > > sysfs_dev = next_dev, next_dev = sysfs_dev ? > > > sysfs_dev->next : NULL) { > > > - if (!sysfs_dev->have_driver) { > > > + if (!sysfs_dev->have_driver && > > > getenv("IBV_SHOW_WARNINGS")) { > > > fprintf(stderr, PFX "Warning: no userspace > > > device-specific " > > > "driver found for %s\n", sysfs_dev > > > ->sysfs_path); > > > if (statically_linked) > > > -- > > > 2.2.1 > > > > > > > >
Hi, Le mardi 19 mai 2015 à 11:36 -0400, Doug Ledford a écrit : > On Tue, 2015-05-19 at 16:14 +0200, Yann Droneaud wrote: > > > > Is Doug the maintainer of the userspace library ? > > Libibverbs and the kernel verbs interface are very closely tied, so I > did ask Roland if he was OK with me taking over that as well. It > would > make it easier to keep the two in sync. Roland was fine with that. > If > anyone has any objections, please speak now. > OK, I think I've missed the memo :) Regards.
On Wed, 2015-05-20 at 16:48 +0200, Yann Droneaud wrote: > Hi, > > Le mardi 19 mai 2015 à 11:36 -0400, Doug Ledford a écrit : > > On Tue, 2015-05-19 at 16:14 +0200, Yann Droneaud wrote: > > > > > > Is Doug the maintainer of the userspace library ? > > > > Libibverbs and the kernel verbs interface are very closely tied, so I > > did ask Roland if he was OK with me taking over that as well. It > > would > > make it easier to keep the two in sync. Roland was fine with that. > > If > > anyone has any objections, please speak now. > > > > > OK, I think I've missed the memo :) No, there wasn't a memo yet. But, Jeff's question followed by your question was the perfect introduction to bring the issue up. As I mentioned, I think there is a pretty strong tie between the kernel stack the libibverbs. Especially when you consider that things like verbs extensions need to be synced between the two. That's why I'm offering/suggesting that it would be a good idea that I handle it along with the kernel.
> As I mentioned, I think there is a pretty strong tie between the kernel > stack the libibverbs. Especially when you consider that things like > verbs extensions need to be synced between the two. That's why I'm > offering/suggesting that it would be a good idea that I handle it along > with the kernel. Where is your upstream libibverbs tree? Or do you have one yet? And where can the latest packages (e.g. 1.1.8) be found?
On Wed, 2015-05-20 at 16:39 +0000, Hefty, Sean wrote: > > As I mentioned, I think there is a pretty strong tie between the kernel > > stack the libibverbs. Especially when you consider that things like > > verbs extensions need to be synced between the two. That's why I'm > > offering/suggesting that it would be a good idea that I handle it along > > with the kernel. > > Where is your upstream libibverbs tree? Or do you have one yet? And where can the latest packages (e.g. 1.1.8) be found? The location of the upstream sources and tarballs would not change. Neither the git repo nor the tarball repo were like the kernel. The upstream kernel.org git repo Roland had, had his name in the repo. So it had to change. But the libibverbs repo is in a generic location. There is no need to change it, only to change the permissions on the git repo to allow the new maintainer to push directly into it. Ditto with the upload/download space on openfabrics.org/downloads/verbs.
On May 20, 2015, at 1:11 PM, Doug Ledford <dledford@redhat.com> wrote: > > The location of the upstream sources and tarballs would not change. > Neither the git repo nor the tarball repo were like the kernel. The > upstream kernel.org git repo Roland had, had his name in the repo. So > it had to change. But the libibverbs repo is in a generic location. > There is no need to change it, only to change the permissions on the git > repo to allow the new maintainer to push directly into it. Did that happen yet? > Ditto with > the upload/download space on openfabrics.org/downloads/verbs. It looks like someone did part of this on flatbed -- you own the download directory but none of the files, and they are all 644. So I took the liberty of chown'ing them all to you: ---- $ hostname; pwd; ls -la flatbed.openfabrics.org /var/www/html/downloads/verbs total 6096 drwxr-xr-x. 2 dledford ofed 4096 May 7 2014 . drwxrwxr-x. 55 apache ofed 4096 Feb 13 07:31 .. -rw-r--r--. 1 dledford ofed 347508 Mar 14 2006 libibverbs-1.0.2.tar.gz -rw-r--r--. 1 dledford ofed 349439 May 2 2006 libibverbs-1.0.3.tar.gz -rw-r--r--. 1 dledford ofed 360410 Oct 31 2006 libibverbs-1.0.4.tar.gz -rw-r--r--. 1 dledford ofed 359902 Jun 18 2007 libibverbs-1.0.5.tar.gz -rw-r--r--. 1 dledford ofed 321835 Aug 29 2005 libibverbs-1.0-rc1.tar.gz -rw-r--r--. 1 dledford ofed 338537 Oct 2 2005 libibverbs-1.0-rc3.tar.gz -rw-r--r--. 1 dledford ofed 341792 Oct 28 2005 libibverbs-1.0-rc4.tar.gz -rw-r--r--. 1 dledford ofed 347699 Feb 17 2006 libibverbs-1.0-rc7.tar.gz -rw-r--r--. 1 dledford ofed 384743 Jun 18 2007 libibverbs-1.1.1.tar.gz -rw-r--r--. 1 dledford ofed 394618 Apr 18 2008 libibverbs-1.1.2.tar.gz -rw-r--r--. 1 dledford ofed 359331 Oct 29 2009 libibverbs-1.1.3.tar.gz -rw-r--r--. 1 dledford ofed 362475 Jun 3 2010 libibverbs-1.1.4.tar.gz -rw-r--r--. 1 dledford ofed 364219 Jun 28 2011 libibverbs-1.1.5.tar.gz -rw-r--r--. 1 dledford ofed 387794 Dec 21 2011 libibverbs-1.1.6.tar.gz -rw-r--r--. 1 dledford ofed 391812 May 28 2013 libibverbs-1.1.7.tar.gz -rw-r--r-- 1 dledford ofed 406548 May 5 2014 libibverbs-1.1.8.tar.gz -rw-r--r--. 1 dledford ofed 384656 Apr 24 2007 libibverbs-1.1.tar.gz -rw-r--r-- 1 dledford ofed 3957 May 7 2014 README.html -rw-r--r--. 1 dledford ofed 60 Mar 12 2008 WEB_README -----
On Fri, 2015-05-22 at 13:58 +0000, Jeff Squyres (jsquyres) wrote: > On May 20, 2015, at 1:11 PM, Doug Ledford <dledford@redhat.com> wrote: > > > > The location of the upstream sources and tarballs would not change. > > Neither the git repo nor the tarball repo were like the kernel. The > > upstream kernel.org git repo Roland had, had his name in the repo. So > > it had to change. But the libibverbs repo is in a generic location. > > There is no need to change it, only to change the permissions on the git > > repo to allow the new maintainer to push directly into it. > > Did that happen yet? I don't think so. I didn't file a specific ticket for it at k.o yet (the k.o tickets take a while to process, so I didn't want to file it until after the comment period here on list). > > Ditto with > > the upload/download space on openfabrics.org/downloads/verbs. > > It looks like someone did part of this on flatbed -- you own the download directory but none of the files, and they are all 644. So I took the liberty of chown'ing them all to you: Yeah, I did that one separately. I had that done earlier, but getting things done on flatbed is much faster and so could be reversed much easier if need be ;-) The reason I didn't own the files is that I didn't really need to. They are more or less set in stone and can't be changed, so being owned by roland's account was fine. It's fine this way too. > ---- > $ hostname; pwd; ls -la > flatbed.openfabrics.org > /var/www/html/downloads/verbs > total 6096 > drwxr-xr-x. 2 dledford ofed 4096 May 7 2014 . > drwxrwxr-x. 55 apache ofed 4096 Feb 13 07:31 .. > -rw-r--r--. 1 dledford ofed 347508 Mar 14 2006 libibverbs-1.0.2.tar.gz > -rw-r--r--. 1 dledford ofed 349439 May 2 2006 libibverbs-1.0.3.tar.gz > -rw-r--r--. 1 dledford ofed 360410 Oct 31 2006 libibverbs-1.0.4.tar.gz > -rw-r--r--. 1 dledford ofed 359902 Jun 18 2007 libibverbs-1.0.5.tar.gz > -rw-r--r--. 1 dledford ofed 321835 Aug 29 2005 libibverbs-1.0-rc1.tar.gz > -rw-r--r--. 1 dledford ofed 338537 Oct 2 2005 libibverbs-1.0-rc3.tar.gz > -rw-r--r--. 1 dledford ofed 341792 Oct 28 2005 libibverbs-1.0-rc4.tar.gz > -rw-r--r--. 1 dledford ofed 347699 Feb 17 2006 libibverbs-1.0-rc7.tar.gz > -rw-r--r--. 1 dledford ofed 384743 Jun 18 2007 libibverbs-1.1.1.tar.gz > -rw-r--r--. 1 dledford ofed 394618 Apr 18 2008 libibverbs-1.1.2.tar.gz > -rw-r--r--. 1 dledford ofed 359331 Oct 29 2009 libibverbs-1.1.3.tar.gz > -rw-r--r--. 1 dledford ofed 362475 Jun 3 2010 libibverbs-1.1.4.tar.gz > -rw-r--r--. 1 dledford ofed 364219 Jun 28 2011 libibverbs-1.1.5.tar.gz > -rw-r--r--. 1 dledford ofed 387794 Dec 21 2011 libibverbs-1.1.6.tar.gz > -rw-r--r--. 1 dledford ofed 391812 May 28 2013 libibverbs-1.1.7.tar.gz > -rw-r--r-- 1 dledford ofed 406548 May 5 2014 libibverbs-1.1.8.tar.gz > -rw-r--r--. 1 dledford ofed 384656 Apr 24 2007 libibverbs-1.1.tar.gz > -rw-r--r-- 1 dledford ofed 3957 May 7 2014 README.html > -rw-r--r--. 1 dledford ofed 60 Mar 12 2008 WEB_README > ----- >
On May 22, 2015, at 9:44 AM, Doug Ledford <dledford@redhat.com> wrote: > >> Did that happen yet? > > I don't think so. I didn't file a specific ticket for it at k.o yet > (the k.o tickets take a while to process, so I didn't want to file it > until after the comment period here on list). Ping. This is just a periodic query to see if there has been any progress on accepting this patch into libibverbs.
On Mon, 2015-06-01 at 22:02 +0000, Jeff Squyres (jsquyres) wrote: > On May 22, 2015, at 9:44 AM, Doug Ledford <dledford@redhat.com> wrote: > > > >> Did that happen yet? > > > > I don't think so. I didn't file a specific ticket for it at k.o yet > > (the k.o tickets take a while to process, so I didn't want to file it > > until after the comment period here on list). > > Ping. > > This is just a periodic query to see if there has been any progress on accepting this patch into libibverbs. > I have a ticket with kernel.org helpdesk to change the permissions on the libibverbs.git repo, and they are waiting on Roland to ACK the change. Until then, I can't do much.
Ping. This is just a periodic query to see if there has been any progress on accepting this patch into libibverbs. > On Jun 3, 2015, at 12:50 PM, Doug Ledford <dledford@redhat.com> wrote: > > On Mon, 2015-06-01 at 22:02 +0000, Jeff Squyres (jsquyres) wrote: >> On May 22, 2015, at 9:44 AM, Doug Ledford <dledford@redhat.com> wrote: >>> >>>> Did that happen yet? >>> >>> I don't think so. I didn't file a specific ticket for it at k.o yet >>> (the k.o tickets take a while to process, so I didn't want to file it >>> until after the comment period here on list). >> >> Ping. >> >> This is just a periodic query to see if there has been any progress on accepting this patch into libibverbs. >> > > I have a ticket with kernel.org helpdesk to change the permissions on > the libibverbs.git repo, and they are waiting on Roland to ACK the > change. Until then, I can't do much. > > -- > Doug Ledford <dledford@redhat.com> > GPG KeyID: 0E572FDD >
> On Jun 16, 2015, at 10:25 AM, Jeff Squyres (jsquyres) <jsquyres@cisco.com> wrote: > > Ping. > > This is just a periodic query to see if there has been any progress on accepting this patch into libibverbs. The patch is accepted, I just haven’t pushed it out yet. > > >> On Jun 3, 2015, at 12:50 PM, Doug Ledford <dledford@redhat.com> wrote: >> >> On Mon, 2015-06-01 at 22:02 +0000, Jeff Squyres (jsquyres) wrote: >>> On May 22, 2015, at 9:44 AM, Doug Ledford <dledford@redhat.com> wrote: >>>> >>>>> Did that happen yet? >>>> >>>> I don't think so. I didn't file a specific ticket for it at k.o yet >>>> (the k.o tickets take a while to process, so I didn't want to file it >>>> until after the comment period here on list). >>> >>> Ping. >>> >>> This is just a periodic query to see if there has been any progress on accepting this patch into libibverbs. >>> >> >> I have a ticket with kernel.org helpdesk to change the permissions on >> the libibverbs.git repo, and they are waiting on Roland to ACK the >> change. Until then, I can't do much. >> >> -- >> Doug Ledford <dledford@redhat.com> >> GPG KeyID: 0E572FDD >> > > > -- > Jeff Squyres > jsquyres@cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > — Doug Ledford <dledford@redhat.com> GPG Key ID: 0E572FDD
T24gSnVuIDE3LCAyMDE1LCBhdCAxMDoyNSBBTSwgRG91ZyBMZWRmb3JkIDxkbGVkZm9yZEByZWRo YXQuY29tPiB3cm90ZToNCj4gDQo+IFRoZSBwYXRjaCBpcyBhY2NlcHRlZCwgSSBqdXN0IGhhdmVu 4oCZdCBwdXNoZWQgaXQgb3V0IHlldC4NCg0KSXMgdGhlcmUgYSB0aW1lbGluZSBmb3Igd2hlbiB0 aGlzIHBhdGNoIHdpbGwgYmUgYXZhaWxhYmxlIGluIHRoZSB1cHN0cmVhbSBnaXQgcmVwbyBhbmQg cmVsZWFzZWQgaW4gYSBuZXcgdmVyc2lvbiBvZiBsaWJpYnZlcmJzPw0KDQpJIGFzayBiZWNhdXNl IHdlJ2QgbGlrZSB0byBzZWUgdGhpcyBwYXRjaCBnZXQgaW50byB1cHN0cmVhbSBkaXN0cm8gbGli aWJ2ZXJicyByZWxlYXNlcy4gIE9uY2UgdGhhdCBoYXBwZW5zLCB3ZSBjYW4gc3RhcnQgcGxhbm5p bmcgdGhlIGVuZCBvZiB0aGUgaG9ycmlibGUgaGFja2Fyb3VuZHMgd2UgaGFkIHRvIHB1dCBpbnRv IHBsYWNlIChlLmcuLCBpbiBPcGVuIE1QSSkgdG8gc3VwcHJlc3MgdGhlIG1pc2xlYWRpbmcgbGli aWJ2ZXJicyBvdXRwdXQuDQoNClRoYW5rcyENCg0KLS0gDQpKZWZmIFNxdXlyZXMNCmpzcXV5cmVz QGNpc2NvLmNvbQ0KRm9yIGNvcnBvcmF0ZSBsZWdhbCBpbmZvcm1hdGlvbiBnbyB0bzogaHR0cDov L3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS8NCg0K -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/06/2015 09:35 AM, Jeff Squyres (jsquyres) wrote: > On Jun 17, 2015, at 10:25 AM, Doug Ledford <dledford@redhat.com> > wrote: >> >> The patch is accepted, I just haven’t pushed it out yet. > > Is there a timeline for when this patch will be available in the > upstream git repo and released in a new version of libibverbs? > > I ask because we'd like to see this patch get into upstream distro > libibverbs releases. Once that happens, we can start planning the > end of the horrible hackarounds we had to put into place (e.g., in > Open MPI) to suppress the misleading libibverbs output. > > Thanks! > The goal I had in mind was to work through this merge window until we are in RCs on kernel stuff, then shift my focus to libibverbs and try to work through a few of the outstanding issues for it and maybe have a release prior to the next merge window for the kernel.
On 05/12/2015 10:14 AM, Jeff Squyres wrote: > It's not a warning or an error if libibverbs cannot find a userspace > driver for kernel devices. Indeed, returning a num_devices of is > sufficient -- the middleware shouldn't be unconditionally printing out > stderr message; let the upper layer application do that (if it wants > to). > > For debugging purposes, if the environment variable IBV_SHOW_WARNINGS > is set (to any value), warnings will be emitted to stderr if a > corresponding userspace driver cannot be found for a kernel device. > > Signed-off-by: Jeff Squyres <jsquyres@cisco.com> > --- > man/ibv_get_device_list.3 | 6 ++++++ > src/init.c | 2 +- > 2 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/man/ibv_get_device_list.3 b/man/ibv_get_device_list.3 > index 16cc1a0..96de554 100644 > --- a/man/ibv_get_device_list.3 > +++ b/man/ibv_get_device_list.3 > @@ -50,6 +50,12 @@ Client code should open all the devices it intends to use with > Once it frees the array with > .B ibv_free_device_list()\fR, > it will be able to use only the open devices; pointers to unopened devices will no longer be valid. > +.P > +Setting the environment variable > +.BR IBV_SHOW_WARNINGS > +will cause warnings to be emitted to stderr if a kernel verbs device > +is discovered, but no corresponding userspace driver can be found for > +it. > .SH "SEE ALSO" > .BR ibv_fork_init (3), > .BR ibv_get_device_name (3), > diff --git a/src/init.c b/src/init.c > index d0e4b1c..dbdd795 100644 > --- a/src/init.c > +++ b/src/init.c > @@ -561,7 +561,7 @@ out: > next_dev = sysfs_dev ? sysfs_dev->next : NULL; > sysfs_dev; > sysfs_dev = next_dev, next_dev = sysfs_dev ? sysfs_dev->next : NULL) { > - if (!sysfs_dev->have_driver) { > + if (!sysfs_dev->have_driver && getenv("IBV_SHOW_WARNINGS")) { > fprintf(stderr, PFX "Warning: no userspace device-specific " > "driver found for %s\n", sysfs_dev->sysfs_path); > if (statically_linked) > This has been applied, thanks.
diff --git a/man/ibv_get_device_list.3 b/man/ibv_get_device_list.3 index 16cc1a0..96de554 100644 --- a/man/ibv_get_device_list.3 +++ b/man/ibv_get_device_list.3 @@ -50,6 +50,12 @@ Client code should open all the devices it intends to use with Once it frees the array with .B ibv_free_device_list()\fR, it will be able to use only the open devices; pointers to unopened devices will no longer be valid. +.P +Setting the environment variable +.BR IBV_SHOW_WARNINGS +will cause warnings to be emitted to stderr if a kernel verbs device +is discovered, but no corresponding userspace driver can be found for +it. .SH "SEE ALSO" .BR ibv_fork_init (3), .BR ibv_get_device_name (3), diff --git a/src/init.c b/src/init.c index d0e4b1c..dbdd795 100644 --- a/src/init.c +++ b/src/init.c @@ -561,7 +561,7 @@ out: next_dev = sysfs_dev ? sysfs_dev->next : NULL; sysfs_dev; sysfs_dev = next_dev, next_dev = sysfs_dev ? sysfs_dev->next : NULL) { - if (!sysfs_dev->have_driver) { + if (!sysfs_dev->have_driver && getenv("IBV_SHOW_WARNINGS")) { fprintf(stderr, PFX "Warning: no userspace device-specific " "driver found for %s\n", sysfs_dev->sysfs_path); if (statically_linked)
It's not a warning or an error if libibverbs cannot find a userspace driver for kernel devices. Indeed, returning a num_devices of is sufficient -- the middleware shouldn't be unconditionally printing out stderr message; let the upper layer application do that (if it wants to). For debugging purposes, if the environment variable IBV_SHOW_WARNINGS is set (to any value), warnings will be emitted to stderr if a corresponding userspace driver cannot be found for a kernel device. Signed-off-by: Jeff Squyres <jsquyres@cisco.com> --- man/ibv_get_device_list.3 | 6 ++++++ src/init.c | 2 +- 2 files changed, 7 insertions(+), 1 deletion(-)