Details
-
Improvement
-
Resolution: Unresolved
-
Major
-
None
-
Lustre 2.7.0
-
None
-
16672
Description
Cray would like to have an LGPL version of the liblustreapi
library. We believe that there is also a desire in the
community to do that move also.
A starting point would be to create that new library with the existing
code already licensed under the LGPL (such as HSM and layout), and
start from there.
We should take this opportunity to do some cleanup in the library, and
start a new one, independent of the older code. Some of the things
that we propose are:
- prefix all API functions with lustre_, as opposed to llapi_
- have a better API to work with the copytool and changelog
readers. As these programs know which filesystem they are dealing
with, there could be an lustre_open_fs / lustre_close_fs type of
API, which would prevent calls to function such as get_root_path for
every request. The HSM API already has something similar, and should
be reused.
- every function must have a test. Currently the liblustreapi is only
tested indirectly with program like lfs, and that's not good enough.
- every function must have a comment describing what it does, its
parameters and return code. This is done for some but not all
functions the existing library.
As a test of the viability for this plan, we'd like to first port the
posix tool to this new API. Currently, besides the API already in some
LGPLed source files, the following functions and their dependencies are needed:
get_param
get_root_path
libcfs_ukuc_get_rfd
libcfs_ukuc_msg_get
libcfs_ukuc_start
libcfs_ukuc_stop
llapi_chomp_string
llapi_create_volatile_idx
llapi_error
llapi_error_callback_set
llapi_fd2fid
llapi_fid2path
llapi_file_open_pool
llapi_get_agent_uuid
llapi_get_mdt_index_by_fid
llapi_msg_set_level
llapi_open_by_fid
llapi_parse_size
llapi_search_fsname
llapi_search_mounts
Cray would like to do the preliminary implementation of this new library, and would like to know if the copyright holders of the above mentioned functions agree to relicense their code under the LGPL. Otherwise they will have to be recoded.
The second phase would be to also port Robinhood to it, since the most
of the API should be there already, except for the changelog
processing.
Attachments
Issue Links
- is duplicated by
-
-
- Resolved
-
- is related to
-
LU-6202 clean up ioctl handling
-
- Open
-
-
-
- Resolved
-
-
LU-9897 Tracking of lustre library improvements.
-
- Open
-
-
-
- Resolved
-
-
-
- Resolved
-
-
LU-6613
lib-dlc.h is under LGPLv3
-
- Resolved
-
- is related to
-
-
- Open
-
Activity
| Link | New: This issue is related to SEA-466 [ SEA-466 ] |
| Link | Original: This issue is related to SEA-466 [ SEA-466 ] |
| Link | New: This issue is related to SEA-466 [ SEA-466 ] |
| Link | New: This issue is related to LDEV-586 [ LDEV-586 ] |
| Comment |
[ It seems to me we have a good opportunity here to refactor our user space utilities out of the Lustre tree. If we define a clean kernel-user interface, then our user space tools won't be dependent on Lustre internals, and we can move all the utilities into their own repository. This will make tool development easier since a tool-only patch would not require a full build and test of the entire Lustre stack, as it does today. The faster development cycle may encourage experimentation and new tool development. It would also provide an easier entry path for new developers interested in contributing to Lustre, but intimidated with the level of effort require to contribute even small changes to the core tree. (A level of effort which is certainly understandable for kernel modules, but perhaps not as much for more fungible utilities.) If this is not a desirable goal we, as a community, want to work towards, then I agree that it makes sense to provide both the base primitives and abstract interface in a single library in the tree, and I'd be OK with that. On the other hand, if this is desirable then perhaps this ticket should be about providing the right LGLP library so Frank's library can continue to to develop externally instead of being incorporated. ] |
| Comment |
[ It seems to me we have a good opportunity here to refactor our user space utilities out of the Lustre tree. If we define a clean kernel-user interface, then our user space tools won't be dependent on Lustre internals, and we can move all the utilities into their own repository. This will make tool development easier since a tool-only patch would not require a full build and test of the entire Lustre stack, as it does today. The faster development cycle may encourage experimentation and new tool development. It would also provide an easier entry path for new developers interested in contributing to Lustre, but intimidated with the level of effort require to contribute even small changes to the core tree. (A level of effort which is certainly understandable for kernel modules, but perhaps not as much for more fungible utilities.) If this is not a desirable goal we, as a community, want to work towards, then I agree that it makes sense to provide both the base primitives and abstract interface in a single library in the tree, and I'd be OK with that. On the other hand, if this is desirable then perhaps this ticket should be about providing the right LGLP library so Frank's library can continue to to develop externally instead of being incorporated. ] |