Brice Goglin, le mer. 26 mai 2021 14:13:02 +0200, a ecrit:
> os_index is already *unsigned* in the API (did you mean signed?). We cannot
> change the obj->os_index back to signed now, it would break existing users.
Mmm, it wouldn't break the ABI, only printf formats using %u?
Samuel
Jirka Hladky, le ven. 06 sept. 2019 16:52:30 +0200, a ecrit:
> The trouble is that other Linux tools (like ps) are using the physical
> numbering.
Yes, that is why hwloc provides both, and hwloc-calc can be used to
convert between them for instance.
Samuel
Brice Goglin, le ven. 06 sept. 2019 16:07:13 +0200, a ecrit:
> physical_package_id don't have to be between 0 and N-1,
Which is the very reason for the logical IDs that hwloc provide :)
Samuel
___
hwloc-devel mailing list
hwloc-devel@lists.open-mpi.org
Hello,
The last missing bits for having hwloc2 in Debian are almost there:
- librsb has been updated in unstable to the fixed 1.2.0.8
- openmpi 4 has been uploaded to experimental
So once openmpi 4 is in unstable and these two are ready to move to
testing, AFAICT there nothing that prevents
Marco Atzeri, le dim. 30 sept. 2018 20:02:59 +0200, a ecrit:
> also adding a HWLOC_DECLSPEC on the first case distances.c:347
> does not solve the issue as the two declaration are not the same.
>
> Suggestion ?
Perhaps use hwloc_uint64_t instead of uint64_t in hwloc/distances.c?
Samuel
Hello,
For information, Homebrew bumped its hwloc version to 2:
https://github.com/Homebrew/homebrew-core/pull/23721
Samuel
___
hwloc-devel mailing list
hwloc-devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/hwloc-devel
Brice Goglin, on lun. 05 févr. 2018 14:25:58 +0100, wrote:
> configure only looks for CL/cl_ext.h before enabling the OpenCL backend.
> Did it enable OpenCL on your machine?
Possibly not, we just happen to have had StarPU build errors when
including opencl.h.
Samuel
BTW, I have noticed that ia64 eventually tried to build beta1. It failed
in the shmem.c test:
https://buildd.debian.org/status/fetch.php?pkg=hwloc=ia64=2.0.0~beta1-4=1517101408=0
I don't have access to a porterbox to check what happened more
precisely. The rc2 build might be attempted within a
Brice Goglin, on lun. 08 janv. 2018 15:41:02 +0100, wrote:
> Do we want to see OpenCL CPU devices too?
I believe we don't want them.
Samuel
___
hwloc-devel mailing list
hwloc-devel@lists.open-mpi.org
Brice Goglin, on ven. 29 déc. 2017 11:15:09 +0100, wrote:
> I couldn't test since binding doesn't seem to work in my qemu (always
> goes to PU #0), even when using qemu-x86_64 on x86_64. Is this fixed
> with your patches sent to qemu-devel yesterday?
My get/setaffinity patches shouldn't fix
Brice Goglin, on jeu. 28 déc. 2017 18:47:29 +0100, wrote:
> Le 28/12/2017 à 16:18, Samuel Thibault a écrit :
> > Samuel Thibault, on jeu. 28 déc. 2017 15:08:30 +0100, wrote:
> >> Samuel Thibault, on mer. 20 déc. 2017 18:32:48 +0100, wrote:
> >>> I have uploaded it t
Samuel Thibault, on jeu. 28 déc. 2017 15:08:30 +0100, wrote:
> Samuel Thibault, on mer. 20 déc. 2017 18:32:48 +0100, wrote:
> > I have uploaded it to debian experimental, so when it passes NEW,
> > various arch test results will show up on
> >
> > https://buildd.debi
Samuel Thibault, on mer. 20 déc. 2017 18:32:48 +0100, wrote:
> I have uploaded it to debian experimental, so when it passes NEW,
> various arch test results will show up on
>
> https://buildd.debian.org/status/package.php?p=hwloc=experimental
>
> so you can check the resu
In the end, I'm wondering what we will do for the Debian packages: a
separate libhwloc2-dev package (which is a pain for various reasons) or
not. It depends whether we have rdependencies ready when we really want
hwloc2 into Debian. FI, here are the rdeps:
Package: gridengine
Package: htop
Brice Goglin, on ven. 22 déc. 2017 12:35:35 +0100, wrote:
> That won't work. You can have memory attached at different levels of the
> hierarchy (things like HBM inside a die, normal memory attached to a
> package, and slow memory attached to the memory interconnect). The
> notion of NUMA node and
BTW, I find differing information on the soname that hwloc2 will have:
https://github.com/open-mpi/hwloc/wiki/Upgrading-to-v2.0-API mentions
version 6, but VERSION uses 12:0:0 (and thus the soname uses 12).
Samuel
___
hwloc-devel mailing list
Hello,
Brice Goglin, on mar. 19 déc. 2017 11:48:39 +0100, wrote:
> + Memory, I/O and Misc objects are now stored in dedicated children lists,
> not in the usual children list that is now only used for CPU-side objects.
> - hwloc_get_next_child() may still be used to iterate over these 4
Samuel Thibault, on mer. 20 déc. 2017 18:26:37 +0100, wrote:
> Brice Goglin, on mer. 20 déc. 2017 18:16:34 +0100, wrote:
> > Le 20/12/2017 à 18:06, Samuel Thibault a écrit :
> > > It has only one NUMA node, thus triggering the code I patched over.
> >
> > We
I have uploaded it to debian experimental, so when it passes NEW,
various arch test results will show up on
https://buildd.debian.org/status/package.php?p=hwloc=experimental
so you can check the results on odd systems :)
Samuel
___
hwloc-devel
Brice Goglin, on mer. 20 déc. 2017 18:16:34 +0100, wrote:
> Le 20/12/2017 à 18:06, Samuel Thibault a écrit :
> > It has only one NUMA node, thus triggering the code I patched over.
>
> Well, this has been working fine for a while, since that's my daily
> development machine a
Brice Goglin, on mer. 20 déc. 2017 17:53:54 +0100, wrote:
> Le 20/12/2017 à 17:49, Samuel Thibault a écrit :
> > Samuel Thibault, on mer. 20 déc. 2017 13:57:45 +0100, wrote:
> >> Brice Goglin, on mar. 19 déc. 2017 11:48:39 +0100, wrote:
> >>> The Hardware Lo
Samuel Thibault, on mer. 20 déc. 2017 13:57:45 +0100, wrote:
> Brice Goglin, on mar. 19 déc. 2017 11:48:39 +0100, wrote:
> > The Hardware Locality (hwloc) team is pleased to announce the first
> > beta release for v2.0.0:
> >
> >http://www.open-mpi.org/projects/h
Brice Goglin, on mar. 19 déc. 2017 11:48:39 +0100, wrote:
> The Hardware Locality (hwloc) team is pleased to announce the first
> beta release for v2.0.0:
>
>http://www.open-mpi.org/projects/hwloc/
I tried to build the Debian package, there are a few failures in the
testsuite:
FAIL:
Hello,
Brice Goglin, on mar. 19 déc. 2017 11:48:39 +0100, wrote:
> The Hardware Locality (hwloc) team is pleased to announce the first
> beta release for v2.0.0:
>
>http://www.open-mpi.org/projects/hwloc/
The tarball doesn't contain a netloc/ directory. This is not a problem
for ./configure
Brice Goglin, on mer. 27 sept. 2017 20:39:47 +0200, wrote:
> Le 27/09/2017 18:58, Samuel Thibault a écrit :
> > Isn't it better to show OpenCL at the root rather then not at all?
>
> As you want.
> If there's a need for these objects without any topology information,
> that'
Brice Goglin, on mar. 29 août 2017 18:54:03 +0200, wrote:
> Contrary to lstopo, hwloc-ps has no problem with long command-lines.
Right.
> What's the point of shortening to comm here?
Well, for coherency only, if you prefer long command-lines there, I'm
fine with it.
Samuel
Jeff Squyres (jsquyres), on Wed 08 Feb 2017 15:19:58 +, wrote:
> 1. You reverted an actual grammar fix: "support" -> "supported".
Oops, I missed that part, sorry.
> 2. I don't think that "likely" is bad to have. Like I said above, the test
> itself is just a switch/case test based on a
git...@open-mpi.org, on Tue 07 Feb 2017 09:15:01 -0600, wrote:
> commit 96a1a1b4d9f4d34e6b26ed4a665a739fd449131a
> Author: Jeff Squyres
> Date: Tue Feb 7 10:13:27 2017 -0500
>
> hwloc.m4: minor english fixes
>
> Signed-off-by: Jeff Squyres
Brice Goglin, on Tue 05 Apr 2016 10:39:29 +0200, wrote:
> Le 05/04/2016 10:26, Samuel Thibault a écrit :
> > The bug here is that that HWLOC_CHECK_DECL assumed that availability
> > of the function was tested before, i.e.
> >> conftest.c(96) : fatal error C1083: Cannot ope
Paul Hargrove, le Tue 28 Jul 2015 16:47:37 -0700, a écrit :
> : "=a" (*eax), "=r" (*ebx), "=c" (*ecx), "=d" (*edx)
>
> 5f5c5: 87 d3 xchg %edx,%ebx
Ouch.
That I call "buggy" indeed :)
Thanks for the tests, that's good to know.
Samuel
Paul Hargrove, le Tue 28 Jul 2015 15:00:36 -0700, a écrit :
> Well, for the compiler that accepted the "=r" form and then generated code
> that
> SEGV'd I would say "buggy".
I would like to see the generated code before saying anything, since
it's so easy to write bogus inline assembly and being
Paul Hargrove, le Tue 21 Jul 2015 16:15:24 -0700, a écrit :
> I am glad you asked me to test widely, because I did find 2 compilers that
> rejected my version with "=r" and one that generated bad code for that case.
What kind of bad code was it generating? Perhaps it was due to not using
an early
Brice Goglin, le Tue 28 Jul 2015 16:13:49 +0200, a écrit :
> and your commit is slightly different: (s/xchg/mov/ and removed last line).
xchg is spurious here, mov is enough. I didn't remove the last line, I
just kept the original source, which uses +a instead of =a and a.
> FWIW, in master we
Hello,
Paul Hargrove, le Mon 20 Jul 2015 23:12:10 -0700, a écrit :
> I believe the following inline x86 asm is correct and more robust than the
> existing code that pgi appears to reject:
Indeed, in the 32bit case, we don't need to shuffle between 32 and 64bit
values, so it's simpler to just use
Peter Korsgaard, le Tue 12 May 2015 16:09:55 +0200, a écrit :
> Make install contains a race condition in utils/hwloc, as both
> install-exec-hook (through intall-exec) and install-data trigger
> install-man:
I'm surprised: isn't make supposed to handle this kind of dependency
concurrency?
Brice Goglin, le Mon 03 Nov 2014 11:49:02 +0100, a écrit :
> * kerrighed support (single-system image): planned for removal since
> 2012, see https://github.com/open-mpi/hwloc/issues/73
Right, Kerrighed is mostly discontinued.
> I am also considering this change that shouldn't break existing
Jeff Squyres (jsquyres), le Fri 12 Sep 2014 10:44:03 +, a écrit :
> I did a test import of hwloc's Trac tickets to githib -- what do you think?
>
> https://github.com/ompiteam/hwloc-test-ticket-import/issues
It looks good to me.
I have unwatched the github hwloc project.
Samuel
Hello,
Ralph Castain, le Wed 10 Sep 2014 17:41:17 -0700, a écrit :
> Just got this from Clang 3.4.2 on Linux x86-64:
>
> In file included from topology-x86.c:23:
> /home/common/openmpi/svn-trunk/opal/mca/hwloc/hwloc191/hwloc/include/private/
> cpuid-x86.h:67:3: warning: extension used
Balaji, Pavan, le Thu 04 Sep 2014 14:39:38 +, a écrit :
> /home/autotest/balaji/hwloc/hwloc-1.9.1/include/private/misc.h:360:3: error:
> implicit declaration of function 'strncasecmp'
> [-Werror=implicit-function-declaration]
Uh, that's odd, we explicitly test for
Brice Goglin, le Wed 29 Jan 2014 16:04:54 +0100, a écrit :
> We may want to make inputbuffer and outputbuffer generic enough (void* +
> length) so that the model works for other architectures one day?
Probably, yes.
> Xen will know that they correspond to inputbuffer=one-register and
>
Hello,
Brice Goglin, le Tue 07 Jan 2014 12:54:45 +0100, a écrit :
> I currently have a crazy idea for getting at the cache information.
> topology-x86.c has a lot of cpuid knowledge, and I have a proposed new
> hypercall which executes cpuid on a specific PU. Would it be possible
Andrew Cooper, le Thu 26 Dec 2013 23:31:36 +0100, a écrit :
> On 26/12/2013 21:43, Samuel Thibault wrote:
> > Andrew Cooper, le Thu 26 Dec 2013 22:17:38 +0100, a écrit :
> >> I believe can make a topology-xen.c without too much trouble. It likely
> >> wants to checked
Samuel Thibault, le Thu 26 Dec 2013 22:43:35 +0100, a écrit :
> Andrew Cooper, le Thu 26 Dec 2013 22:17:38 +0100, a écrit :
> > I believe can make a topology-xen.c without too much trouble. It likely
> > wants to checked before an os-specific hook (Xen dom0's come in at least
>
Hello,
Andrew Cooper, le Thu 26 Dec 2013 22:17:38 +0100, a écrit :
> I believe can make a topology-xen.c without too much trouble. It likely
> wants to checked before an os-specific hook (Xen dom0's come in at least
> Linux, FreeBSD, NetBSD flavours which have mainstream support)
> Are there any
Pavan Balaji, le Fri 06 Dec 2013 00:34:30 +0100, a écrit :
> Would you consider the following patch for hwloc-1.8 that we embed in the
> mpich version of hwloc? The commit log has the description. Please ignore
> the extra white-space piece of the commit.
This is now commited in master and
Jeff Squyres (jsquyres), le Fri 01 Nov 2013 18:03:55 +0100, a écrit :
> On Nov 1, 2013, at 11:54 AM, Samuel Thibault <samuel.thiba...@inria.fr> wrote:
>
> > We could avoid Xutil.h and keysym.h by disabling the case KeyPress part,
> > but I'd rather not: people will wo
Jeff Squyres (jsquyres), le Fri 01 Nov 2013 16:33:41 +0100, a écrit :
> There's some funny m4 logic in the CHECK_HEADERS for X11. Let me make sure I
> understand the intent:
>
> - X11/Xlib.h: this file is required for X11 support
> - X11/Xutil.h X11/keysym.h: these files are optional for X11
Jeff Squyres (jsquyres), le Fri 01 Nov 2013 16:01:41 +0100, a écrit :
> It looks like this logic isn't quite correct, anyway -- the X11 checks are
> embedded in the Cairo and GL sections. Should they moved out to be
> independent of Cairo and GL (and therefore only once, and include the
>
Jeff Squyres (jsquyres), le Fri 01 Nov 2013 15:12:31 +0100, a écrit :
> Cool. Does the following patch look ok? If so, I'll commit to master and
> v1.7:
Err, no, we really need to have HWLOC_HAVE_X11 defined when X11 is
available, otherwise we won't get the graphical lstopo.
Samuel
Hello,
Jeff Squyres (jsquyres), le Fri 01 Nov 2013 14:59:03 +0100, a écrit :
> I notice that we have an explicit dependency between Cairo and X11 in
> configure:
>
> Is there any reason for this?
I think if there was any it's now gone.
> Indeed, I manually disabled this extra check in
Samuel Thibault, le Thu 03 Oct 2013 18:01:25 +0200, a écrit :
> I have automatically imported the previous debian uploads. I don't
> think we really need to keep the detailed commit, the releases have
> brought small diffs enough.
And that permits to switch to another layout which
Jeff Squyres (jsquyres), le Thu 03 Oct 2013 12:38:05 +0200, a écrit :
> On Oct 2, 2013, at 12:47 PM, Brice Goglin wrote:
> > I can do it (assuming the "hwloc-svn-conversion" git tree it uptodate).
> > But I need somebody to create the ompi/hwloc-debian repo on github and
>
Jeff Squyres (jsquyres), le Fri 27 Sep 2013 15:36:33 +0200, a écrit :
> a) The last SVN nightly snapshot on the v1.7 branch was named
>hwloc-1.7.3rc1r5779.tar.bz2.
> b) The first git nightly snapshot on the v1.7 branch will be named
>hwloc-1.7.2-4-g3a6f84c.tar.bz2.
>
> Note
Jeff Squyres (jsquyres), le Sat 07 Sep 2013 00:04:13 +0200, a écrit :
> What are your github IDs?
sthibaul
Samuel
Brice Goglin, le Thu 29 Aug 2013 09:58:17 +0200, a écrit :
> Anyway, reversing the loop just move the core you don't want to the end of the
> list. But if you use the entire list, you end up using the exact same cores.
He wants that, yes.
Samuel
Brice Goglin, le Thu 18 Jul 2013 14:10:28 +0200, a écrit :
> * only put the prototypes in hwloc.h and keep the inline code somewhere else
> * if some sections are obviously less important, keep these out of
> hwloc.h (just like the ones in hwloc/helper.h currently)
I'd say these two.
Samuel
Jiri Hladky, le Thu 20 Jun 2013 22:08:03 +0200, a écrit :
> lstopo has obviously some logic how to sort the data inserted
> by hwloc_topology_insert_misc_object_by_cpuset. Could be data displayed in the
> same order as inserted?
hwloc_topology_insert_misc_object_by_parent probably does that, you
Hello,
Jiri Hladky, le Tue 18 Jun 2013 17:18:15 +0200, a écrit :
> I would like to check the possibilities to visualize the results to the output
> similar to lstopo --top (see the attachment). I would like to write a simple
> utility which will
> * parse the above file
> * foreach timestep
Brice Goglin, le Mon 03 Jun 2013 19:50:26 +0200, a écrit :
> Le 03/06/2013 10:52, Samuel Thibault a écrit :
> > Brice Goglin, le Mon 03 Jun 2013 10:46:49 +0200, a écrit :
> >> hwloc/bitmap.h is the biggest problem, plugins should be allowed to use
> >> all of them but
Brice Goglin, le Mon 03 Jun 2013 10:46:49 +0200, a écrit :
> hwloc/bitmap.h is the biggest problem, plugins should be allowed to use
> all of them but there are many of them. Splitting hwloc-bitmap.so
> out of hwloc.so would be an easy way to solve this. The bitmap API is
> totally independent
Jeff Squyres (jsquyres), le Wed 08 May 2013 02:21:02 +0200, a écrit :
> On May 7, 2013, at 6:25 PM, Brice Goglin wrote:
>
> > I don't have anything against this. What was the reason for not using
> > the default/system libltdl in OMPI? libtool was buggy when you started
>
Pavan Balaji, le Fri 03 May 2013 06:45:10 +0200, a écrit :
> -Wbad-function-cast'.
>
> lstopo-draw.c:437: warning: cast from function call of type 'double' to
> non-matching type 'unsigned int'
I'm not sure to understand what one is supposed to do here.
double->float->unsigned is less precise
Paul Hargrove, le Wed 24 Apr 2013 08:06:03 +0200, a écrit :
> In my testing on Fedora 17, the patch below applied to hwloc-1.7 produces an
> accurate sys_lib_dlsearch_path_spec
>
> --- config/libtool.m4~ 2013-04-07 16:29:21.0 -0700
> +++ config/libtool.m4 2013-04-23 22:43:52.88200
Hello,
Jiri Hladky, le Sat 20 Apr 2013 00:57:18 +0200, a écrit :
> topology-gl.c: In function 'hwloc_gl_query_devices':
> topology-gl.c:91:41: error: 'NV_CTRL_PCI_DOMAIN' undeclared (first use in this
>
> Indeed, there is no NV_CTRL_PCI_DOMAIN MACRO defined in NVCtrl header files:
>
> grep
Samuel Thibault, le Fri 05 Apr 2013 14:08:16 +0200, a écrit :
> Samuel Thibault, le Fri 05 Apr 2013 09:11:31 +0200, a écrit :
> > Brice Goglin, le Thu 04 Apr 2013 18:02:33 +0200, a écrit :
> > > I haven't seen any problem on various Linux distribs, several BSDs, some
> >
Samuel Thibault, le Fri 05 Apr 2013 09:11:31 +0200, a écrit :
> Brice Goglin, le Thu 04 Apr 2013 18:02:33 +0200, a écrit :
> > I haven't seen any problem on various Linux distribs, several BSDs, some
> > Solaris, and AIX 6.1.
>
> Same for me (including hp-ux).
Ah, mic devi
Brice Goglin, le Thu 04 Apr 2013 18:02:33 +0200, a écrit :
> I haven't seen any problem on various Linux distribs, several BSDs, some
> Solaris, and AIX 6.1.
Same for me (including hp-ux).
Samuel
Hello,
I'm realizing that this was actually not settled on. I've just fixed my
previous text with the current syntax
Samuel Thibault, le Mon 07 Jan 2013 15:05:55 +0100, a écrit :
> Brice Goglin, le Mon 31 Dec 2012 10:05:41 +0100, a écrit :
> > + The HWLOC_COMPONENTS may
Christopher Samuel, le Tue 19 Feb 2013 05:30:40 +0100, a écrit :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/02/13 10:29, Samuel Thibault wrote:
>
> > Right. If hwloc was strictly requiring a GPL library to be able
> > to run, providing it under BSD wo
Brice Goglin, le Fri 08 Feb 2013 13:34:01 +0100, a écrit :
> Le 08/02/2013 13:26, Samuel Thibault a écrit :
> > Brice Goglin, le Fri 08 Feb 2013 13:23:33 +0100, a écrit :
> >> Le 08/02/2013 12:52, Samuel Thibault a écrit :
> >>> svn-commit-mai...@open-mpi.org, le
Brice Goglin, le Fri 08 Feb 2013 13:23:33 +0100, a écrit :
> Le 08/02/2013 12:52, Samuel Thibault a écrit :
> > svn-commit-mai...@open-mpi.org, le Fri 08 Feb 2013 12:02:18 +0100, a écrit :
> >> Everything is hardwired in the backend, all nodes are the same.
> > Would it b
Brice Goglin, le Wed 06 Feb 2013 07:11:03 +0100, a écrit :
> Any idea why it doesn't find your nvidia card?
Actually it is due to my use of bumblebee, which puts the graphic card
into sleep when not running CUDA. Running lstopo through optirun brings
the card back. It actually makes sense, I
Jeff Squyres (jsquyres), le Wed 06 Feb 2013 17:33:03 +0100, a écrit :
> On Feb 6, 2013, at 8:21 AM, Samuel Thibault <samuel.thiba...@inria.fr> wrote:
>
> >> - if found, and if --enable-gpl-taint was specified, use it. STOP.
> >
> > Such kind of options are quest
Brice Goglin, le Wed 06 Feb 2013 16:03:21 +0100, a écrit :
> I am not sure yet if we should add a
> --disable-gpl or --enable-gpl,
Jeff Squyres (jsquyres), le Wed 06 Feb 2013 16:11:55 +0100, a écrit :
> - if found, and if --enable-gpl-taint was specified, use it. STOP.
Such kind of options are
Brice Goglin, le Wed 06 Feb 2013 07:11:03 +0100, a écrit :
> Any idea why it doesn't find your nvidia card?
Well, actually it does, but vendor id & co are all 0x
> By the way, the contamination should be limited to the libpci plugin
> when plugins are enabled.
Right.
Samuel
Samuel Thibault, le Wed 06 Feb 2013 01:55:18 +0100, a écrit :
> Jeff Squyres (jsquyres), le Wed 06 Feb 2013 01:41:21 +0100, a écrit :
> > On Feb 5, 2013, at 3:50 PM, Samuel Thibault <samuel.thiba...@inria.fr>
> > wrote:
> >
> > > Jeff Squyres (jsquyres
Jeff Squyres (jsquyres), le Wed 06 Feb 2013 01:41:21 +0100, a écrit :
> On Feb 5, 2013, at 3:50 PM, Samuel Thibault <samuel.thiba...@inria.fr> wrote:
>
> > Jeff Squyres (jsquyres), le Tue 05 Feb 2013 22:52:01 +0100, a écrit :
> >> It was just pointed out to me th
Jeff Squyres (jsquyres), le Tue 05 Feb 2013 22:52:01 +0100, a écrit :
> It was just pointed out to me that libpci is licensed under the GPL (not the
> LGPL).
I'm told that we could use libpciaccess instead, which is BSD.
Samuel
Pavan Balaji, le Tue 05 Feb 2013 23:53:54 +0100, a écrit :
> I checked libnuma, which seems to be LGPL (phew!), but didn't look at
> the remaining libraries hwloc uses.
The base of hwloc needs libm/libc (LGPL), plugin support needs libltdl
(LGPL) and libdl (LGPL).
Samuel
Pavan Balaji, le Wed 06 Feb 2013 00:07:10 +0100, a écrit :
>
> On 02/05/2013 04:52 PM US Central Time, Pavan Balaji wrote:
> > If libpci was disabled by default, would hwloc still come under the same
> > GPL issue?
>
> I realized that wasn't very clear. Let me rephrase -- if libpci was
>
Jeff Squyres (jsquyres), le Tue 05 Feb 2013 22:52:01 +0100, a écrit :
> The complaint to me was that hwloc needs to be clearer about this in its
> documentation.
>
> Does this sound right?
It makes sense that we warn about this, yes, so people know they might
want to pass --disable-pci.
Samuel
Jeff Squyres (jsquyres), le Mon 07 Jan 2013 20:01:44 +0100, a écrit :
> So if you don't know the list of available components, is it not possible to
> specify *only* foo and bar should be used?
foo,bar,stop
will do it.
Samuel
Brice Goglin, le Mon 07 Jan 2013 19:11:02 +0100, a écrit :
> BTW, if we change the hwloc syntax, we may want to not use ^ to avoid
> confusion with OMPI. ~ and ! could work but some shells may not like them?
How about '-'? I doubt anybody would want a plugin name starting with
it.
Samuel
Jeff Squyres (jsquyres), le Mon 07 Jan 2013 19:19:15 +0100, a écrit :
> On Jan 7, 2013, at 12:59 PM, Samuel Thibault <samuel.thiba...@inria.fr>
> > Because I may not know *everything* that I want. Who knows what
> > proprietary plugin I need to use to discover CPUs, while I k
Brice Goglin, le Mon 07 Jan 2013 17:33:47 +0100, a écrit :
> Ideally, we could even have a OS device for each OpenCL platform, each
> containing OS devices for devices of the platform. But I'd rather keep a
> single level to match other OS devices.
In most cases the platform object wouldn't bring
Hello,
Brice Goglin, le Mon 31 Dec 2012 10:05:41 +0100, a écrit :
> + The HWLOC_COMPONENTS may now start with '^' to only define a list of
> components to exclude.
I'm finding it not intuitive and not generic enough, I'm wondering how
that didn't affect Open-MPI, which as IUI uses this
Brice Goglin, le Mon 31 Dec 2012 10:05:41 +0100, a écrit :
> - They add OS devices such as opencl0p0,
I see that platform 0 device 3 would be called opencl3p0. I find it
counterintuitive, and would have rather called it opencl0d3, along the
line of sda3, eth0:3, socket:2.core:0, etc.
What do
Brice Goglin, le Thu 08 Nov 2012 13:48:39 +0100, a écrit :
> Did anybody look at leastc at the documentation links below?
Yep, it looks nice!
Samuel
Sebastian Kuzminsky wrote:
> Maybe lstopo should expand its cpuset to be fully inclusive at startup? I'll
> be happy to test patches if you want.
Brice Goglin, le Thu 11 Oct 2012 18:13:53 +0200, a écrit :
> Is the cpuset-modification a root-only operation on FreeBSD? If so lstopo
> wouldn't be
Brice Goglin, le Tue 25 Sep 2012 11:08:04 +0200, a écrit :
> >> We have the "core_xml" component (generic xml support) and "xml_libxml"
> >> + "xml_nolibxml" backends behind that. I am fine with removing the
> >> "core_" prefix, but I wonder if we should keep the "xml_" prefix for the
> >> latter.
Brice Goglin, le Tue 25 Sep 2012 10:34:29 +0200, a écrit :
> I am also going to add a hwloc_ prefix to plugin filenames because we
> obviously can't create a libpci.so (libtool even warns about this).
And it makes things clearer, I believe.
> XML backends could be hwlocxml_ (not hwloc_xml_) to
Brice Goglin, le Tue 25 Sep 2012 07:41:48 +0200, a écrit :
> * Your HWLOC_PLUGINS variable is not about loading plugins, it's about
> enabling core components.
It could also be to use another PCI detection plugin that libpci.
Samuel
Hello,
Brice Goglin, le Mon 24 Sep 2012 22:04:14 +0200, a écrit :
> 1) A rework of the backend infrastructure to make the core much more
> readable (basically all changes in *.[ch] files).
That looks nicer indeed.
> 2) Plugin support
One thing that doesn't seem implemented yet is to choose
Jeff Squyres, le Thu 06 Sep 2012 15:46:29 +0200, a écrit :
> On Sep 6, 2012, at 7:46 AM, Jeff Squyres wrote:
> > (sorry; I forgot to ping Shiqing yesterday -- I just did so now to get a
> > confirmation of what you found)
>
>
> Shiqing confirms that DSOs are disabled by default on Windows.
Jeff Squyres, le Wed 05 Sep 2012 17:06:00 +0200, a écrit :
> On Sep 5, 2012, at 10:21 AM, Samuel Thibault wrote:
>
> > So ltdl does not help for that matter?
>
> No. It's not really an ltdl issue. ltdl is just a portable wrapper around
> OS-specific dlopen-like mechan
Brice Goglin, le Wed 05 Sep 2012 16:13:31 +0200, a écrit :
> The problem I was trying to fix below is that linking hwloc plugins on
> Darwin failed because plugins referred to hwloc-core symbols. Nothing on
> the libtool command-line said where to find those symbols (I don't
> understand why it
Brice Goglin, le Wed 22 Aug 2012 07:52:07 +0200, a écrit :
> Le 21/08/2012 21:18, Samuel Thibault a écrit :
> > Brice Goglin, le Tue 21 Aug 2012 18:49:48 +0200, a écrit :
> >> 1) We load plugins and list existing components once per topology. We
> >> should
Pavan Balaji, le Sat 21 Jul 2012 04:40:22 +0200, a écrit :
> In hwloc_bitmap_or(), is the resultant bitmap allowed to be the same as one
> of the input bitmaps? It seems to work correctly in practice, but the API
> doesn't seem to explicitly guarantee it.
We actually use it a lot in the core.
Brice Goglin, le Fri 06 Jul 2012 14:50:46 +0200, a écrit :
> I could just use isprint() to check every character
> before export and only keep those between 32 and 127.
Why not just taking 32-126? I don't see what isprint will bring.
> But what about \n,
> \t, \r, \f which are before ? Do we
Brice Goglin, le Fri 29 Jun 2012 22:29:20 +0200, a écrit :
> Arg, I was using the console output (hwloc-nox).
Ah, you should be able to use -.txt then, it colorizes there too.
Samuel
1 - 100 of 431 matches
Mail list logo