Hi. I''m willing to maintain a project hosted on java.net (https://zfs.dev.java.net/) that aims to provide a Java wrapper to libzfs. I''ve already wrapped, although not committed yet, the last libzfs.h I found on OpenSolaris.org (v. 10342:108f0058f837) and the first problem I want to address is library versioning. The existing sources are wrapping an old version of libzfs.h and, as far as I can see, there were changes in libzfs.h history which would disrupt the wrapper functionality and I just wouldn''t like to present the user with linker errors. Rather, I''d like to keep track of libzfs.h "history" during the various Nevada builds and plug the correct wrapper at runtime, during the library bootstrap. Obviously, an user could just choose and use directly the wrapper, which will be the equivalent of linking against libzfs, and do what it wants to with it. Our idea, which the project founder has already brought on, is wrapping much of the functionality (if not all...) behind a hierarchy of Java classes which would take care of the implementation details and shield the user against library changes. The first question is, then: how can I determine which libzfs.h version has gone in which Nevada build? Once I have this information, how would you suggest me to plug the wrapper at runtime? I was thinking about something like uname -rv and use that information to load wrappers, but perhaps there are finest ways to do this. Thanks in advance, Enrico -- Enrico M. Crisostomo
Enrico, Could you compare and contrast your effort with the existing libzfs_jni? http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libzfs_jni/common/ Perhaps it would be worthwhile to try and un-privatize libzfs_jni? -- richard On Sep 10, 2009, at 12:20 PM, Enrico Maria Crisostomo wrote:> Hi. > > I''m willing to maintain a project hosted on java.net > (https://zfs.dev.java.net/) that aims to provide a Java wrapper to > libzfs. I''ve already wrapped, although not committed yet, the last > libzfs.h I found on OpenSolaris.org (v. 10342:108f0058f837) and the > first problem I want to address is library versioning. The existing > sources are wrapping an old version of libzfs.h and, as far as I can > see, there were changes in libzfs.h history which would disrupt the > wrapper functionality and I just wouldn''t like to present the user > with linker errors. Rather, I''d like to keep track of libzfs.h > "history" during the various Nevada builds and plug the correct > wrapper at runtime, during the library bootstrap. Obviously, an user > could just choose and use directly the wrapper, which will be the > equivalent of linking against libzfs, and do what it wants to with it. > Our idea, which the project founder has already brought on, is > wrapping much of the functionality (if not all...) behind a hierarchy > of Java classes which would take care of the implementation details > and shield the user against library changes. > > The first question is, then: how can I determine which libzfs.h > version has gone in which Nevada build? Once I have this information, > how would you suggest me to plug the wrapper at runtime? I was > thinking about something like uname -rv and use that information to > load wrappers, but perhaps there are finest ways to do this. > > Thanks in advance, > Enrico > > -- > Enrico M. Crisostomo > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
On Thu, Sep 10, 2009 at 8:52 PM, Richard Elling <richard.elling at gmail.com> wrote:> Enrico, > Could you compare and contrast your effort with the existing libzfs_jni? > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libzfs_jni/common/Where''s the source for the java code that uses that library? -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
Thanks for pointing it out, Richard. I missed libzfs_jni. I''ll have a look at it and see where we''re overlapping. As far as I can see at a quick glance is that libzfs_jni is including functionality we''d like to build upon the libzfs wrapper (that''s why I was studying zfs and zpool commands). Maybe a convergence may be worthwhile: I''ll study it ASAP. Thanks for the pointer Richard! Enrico The first thing On Thu, Sep 10, 2009 at 9:52 PM, Richard Elling <richard.elling at gmail.com> wrote:> Enrico, > Could you compare and contrast your effort with the existing libzfs_jni? > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libzfs_jni/common/ > > Perhaps it would be worthwhile to try and un-privatize libzfs_jni? > ?-- richard > > On Sep 10, 2009, at 12:20 PM, Enrico Maria Crisostomo wrote: > >> Hi. >> >> I''m willing to maintain a project hosted on java.net >> (https://zfs.dev.java.net/) that aims to provide a Java wrapper to >> libzfs. I''ve already wrapped, although not committed yet, the last >> libzfs.h I found on OpenSolaris.org (v. 10342:108f0058f837) and the >> first problem I want to address is library versioning. The existing >> sources are wrapping an old version of libzfs.h and, as far as I can >> see, there were changes in libzfs.h history which would disrupt the >> wrapper functionality and I just wouldn''t like to present the user >> with linker errors. Rather, I''d like to keep track of libzfs.h >> "history" during the various Nevada builds and plug the correct >> wrapper at runtime, during the library bootstrap. Obviously, an user >> could just choose and use directly the wrapper, which will be the >> equivalent of linking against libzfs, and do what it wants to with it. >> Our idea, which the project founder has already brought on, is >> wrapping much of the functionality (if not all...) behind a hierarchy >> of Java classes which would take care of the implementation details >> and shield the user against library changes. >> >> The first question is, then: how can I determine which libzfs.h >> version has gone in which Nevada build? Once I have this information, >> how would you suggest me to plug the wrapper at runtime? I was >> thinking about something like uname -rv and use that information to >> load wrappers, but perhaps there are finest ways to do this. >> >> Thanks in advance, >> Enrico >> >> -- >> Enrico M. Crisostomo >> _______________________________________________ >> zfs-discuss mailing list >> zfs-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > >-- ????????? ? ??????? "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." GPG key: 1024D/FD2229AF
On Sep 10, 2009, at 1:03 PM, Peter Tribble wrote:> On Thu, Sep 10, 2009 at 8:52 PM, Richard Elling > <richard.elling at gmail.com> wrote: >> Enrico, >> Could you compare and contrast your effort with the existing >> libzfs_jni? >> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libzfs_jni/common/ > > Where''s the source for the java code that uses that library?Excellent question! It is used for the BUI ZFS manager webconsole that comes with S10 and SXCE. So you might find the zfs.jar as /usr/share/webconsole/webapps/zfs/WEB-INF/lib/zfs.jar The jar only contains the class files, though. Someone from Sun could comment on the probability that they will finally get their act together and have a real BUI framework for systems management... they''ve tried dozens (perhaps hundreds) of times, with little to show for the effort :-( -- richard
On Fri, Sep 11, 2009 at 12:26 AM, Richard Elling <richard.elling at gmail.com> wrote:> On Sep 10, 2009, at 1:03 PM, Peter Tribble wrote: >> >> On Thu, Sep 10, 2009 at 8:52 PM, Richard Elling >> <richard.elling at gmail.com> wrote: >>> >>> Enrico, >>> Could you compare and contrast your effort with the existing libzfs_jni? >>> >>> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libzfs_jni/common/ >> >> Where''s the source for the java code that uses that library? > > Excellent question! ?It is used for the BUI ZFS manager webconsole that > comes with S10 and SXCE. So you might find the zfs.jar as > /usr/share/webconsole/webapps/zfs/WEB-INF/lib/zfs.jar > The jar only contains the class files, though.Yes, that''s what I thought when I saw it. Furthermore, the last time I tried it was still unaligned with the new ZFS capabilites: it crashed because of an unknown gzip compression type...> > Someone from Sun could comment on the probability that they > will finally get their act together and have a real BUI framework for > systems management... they''ve tried dozens (perhaps hundreds) > of times, with little to show for the effort :-(By the way, one of the goals I''d like to reach with such kind of library is just that: putting the basis for building a java based management framework for ZFS. Unfortunately wrapping libzfs will hardly fulfill this goal and the more I dig into the code the more I realize that we will need to wrap (or reimplement) some of the logic of the zfs and zpool commands. I''m also confident that building a good library on top of this wrapper will give us a very powerful tool to play with from Java.> ?-- richard > >-- ????????? ? ??????? "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." GPG key: 1024D/FD2229AF
Richard, I compared the libzfs_jni source code and they''re pretty different from what we''re doing. libzfs_jni is essentially a jni wrapper to (yet?) another set of zfs-related programs written in C. zfs for Java, on the other hand, is a Java wrapper to the functionality of (and only of) libzfs. I suppose that libzfs_jni capabilities could be implemented on top of zfs for java but the approach is pretty different: the main difference is the purpose of the exposed methods: libzfs is the interface to ZFS and its methods are low level while libzfs_jni exposes a set of operations which are coarse grained and targeted to management. Nevertheless, the functionality provided by libzfs_jni is interesting and I''d like to build something similar by using zfs for java. Personally, I''m doing this for two reasons: having a libzfs wrapper for Java seems like a good thing to have and I''d like to use to build some management interfaces (such as web but not only) instead on having to rely on shell scripting with zfs and zpool commands. I''ll keep an eye to libzfs_jni. Now, to return to the original question, I haven''t found a way to correlate libzfs.h versions (and dependencies) to Nevada releases. At the moment, I''m willing to extract information from a sysinfo call (any suggestion about a better way?) and the next step, whose logic I''m missing, is how to correlate this information with to a concrete libzfs.h version from openGrok: maybe it''s just trivial, but I do not find it. Have you got some information to help me address this problem? Thanks, Enrico On Fri, Sep 11, 2009 at 12:53 AM, Enrico Maria Crisostomo <enrico.m.crisostomo at gmail.com> wrote:> On Fri, Sep 11, 2009 at 12:26 AM, Richard Elling > <richard.elling at gmail.com> wrote: >> On Sep 10, 2009, at 1:03 PM, Peter Tribble wrote: >>> >>> On Thu, Sep 10, 2009 at 8:52 PM, Richard Elling >>> <richard.elling at gmail.com> wrote: >>>> >>>> Enrico, >>>> Could you compare and contrast your effort with the existing libzfs_jni? >>>> >>>> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libzfs_jni/common/ >>> >>> Where''s the source for the java code that uses that library? >> >> Excellent question! ?It is used for the BUI ZFS manager webconsole that >> comes with S10 and SXCE. So you might find the zfs.jar as >> /usr/share/webconsole/webapps/zfs/WEB-INF/lib/zfs.jar >> The jar only contains the class files, though. > Yes, that''s what I thought when I saw it. Furthermore, the last time I > tried it was still unaligned with the new ZFS capabilites: it crashed > because of an unknown gzip compression type... > >> >> Someone from Sun could comment on the probability that they >> will finally get their act together and have a real BUI framework for >> systems management... they''ve tried dozens (perhaps hundreds) >> of times, with little to show for the effort :-( > By the way, one of the goals I''d like to reach with such kind of > library is just that: putting the basis for building a java based > management framework for ZFS. Unfortunately wrapping libzfs will > hardly fulfill this goal and the more I dig into the code the more I > realize that we will need to wrap (or reimplement) some of the logic > of the zfs and zpool commands. I''m also confident that building a good > library on top of this wrapper will give us a very powerful tool to > play with from Java. > >> ?-- richard >> >> > > > > -- > ????????? ? ??????? > "Programming today is a race between software engineers striving to > build bigger and better idiot-proof programs, and the Universe trying > to produce bigger and better idiots. So far, the Universe is winning." > GPG key: 1024D/FD2229AF >-- ????????? ? ??????? "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." GPG key: 1024D/FD2229AF