On Fri, 2008-07-25 at 10:07 +0100, Mel Gorman wrote: > On (25/07/08 09:12), Andy Whitcroft didst pronounce: > > On Thu, Jul 24, 2008 at 05:41:04PM -0700, Nishanth Aravamudan wrote: > > > On 24.07.2008 [21:48:19 +0100], Andy Whitcroft wrote: > > > > On Thu, Jul 24, 2008 at 01:49:24PM -0500, Adam Litke wrote: > > > > > On Thu, 2008-07-24 at 17:44 +0100, Andy Whitcroft wrote: > > > > > > Add support for requesting a specific library set for preload. > > > > > > This adds > > > > > > the --library option which takes an optional argument. Without an > > > > > > argument > > > > > > it requests use of the specific libraries installed with the version > > > > > > of hugectl in use. An argument is treated as a prefix to the > > > > > > library > > > > > > directories and the approprate 32/64 bit library directories are > > > > > > added. > > > > > > > > > > Hmm, there is a use case that this patch doesn't cover (and it was the > > > > > first thing I thought of when I saw the patch title). Say I have a > > > > > pre-built library in /home/aglitke (or some such path without > > > > > lib/lib64 > > > > > structure) that I want to use. The patch (as it exists now) would not > > > > > let me point hugectl at this library. Am I the only one who thinks > > > > > this > > > > > might be useful? I suppose one option is to make users wanting to do > > > > > this simply use LD_LIBRARY_PATH directly. > > > > > > > > I can probabally sort out a way to specify that too. Will consider it > > > > further in the morning. > > > > > > > > Checking directly for the library in the passed directory name then use > > > > it directly would do the trick. > > > > > > Now, I may have just missed things in the previous editions of this > > > patch and the discussions thereafter, but I feel like this particular > > > patch may be more complicated than it needs to be. For hugectl, I > > > envision one of two use cases: > > > > > > a) Use the system's library resolution (which is either going to have > > > been configured for ld.so via /etc/ld.so.conf or whatever (something > > > distro-specific) or set via LD_LIBRARY_PATH by the administrator/user) > > > to find the library, which should be the default. > > > > > > b) Allow the user to specify the path to the library they would like to > > > use. > > > > > > That is, I dont't think we need any extra options beyond > > > > > > hugectl --library-path= > > > > > > Is there a reason for anything else? I can't think of one from my > > > experience with users/customers. I don't think hugectl should be aware > > > of what library it was installed with. It should just use the normal > > > resolution methods (that is, the default library to load is not > > > hard-coded). That should simplify the patch, as well. > > > > > > FWIW, the comment indicates that --library is the only option being > > > added, but I believe there were two added in the patch. > > > > The default action is to ensure we use the library which matches > > hugectl, that is there so that if you have 2.0 and 2.1 installed you get > > the versions which match the version of hugectl you have selected, much > > as you get the version of libgcc.a that matches the version of gcc you > > are running. If that is not required the yes the patch would simplify. > > > > I like this default as the executables go in hand with their library. > Lets take a case where libhugetlbfs has been installed as part > of some larger package in /opt/OtherPackage/ . If I set my path to > /opt/OtherPackage/bin:$PATH, I'd like hugectl to be using the library in > /opt/OtherPackage/lib and /opt/OtherPackage/lib64 by default instead of > having to remember I also must also update LD_LIBRARY_PATH or specify > something additional on the command line.
Both of these angles: Nish, Andy/Mel make very good points. In order to ensure that the hugectl interface properly meshes with the library interface it is meant to program, I think it's important that we enforce some version pairing. However, when people override libraries, they most often have a specific library _file_ in mind that they want to use. This discussion brings up potentially three things in my opinion: 1) Library / hugectl pairing makes sense especially in the absence of #3 below 2) An option to choose a specific library dir is absolutely necessary if hugectl internally overrides LD_LIBRARY_PATH. Otherwise there would be no facility at all to choose a library (LD_LIBRARY_PATH) left to the user (except for moving files around to trick hugectl's mechanism). 3) Might we want to create version checking interface in libhugetlbfs and when hugectl starts it could check the version and emit a warning if there is a discrepancy? I'm not certain of the best/easiest way to do this yet. -- Adam Litke - (agl at us.ibm.com) IBM Linux Technology Center ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libhugetlbfs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
