Hi Ilya, On 01/23/2017 07:43 PM, Ilya Dryomov wrote: > On Mon, Jan 23, 2017 at 6:00 PM, Loic Dachary <loic@xxxxxxxxxxx> wrote: >> Hi Adam, >> >> On 01/23/2017 05:29 PM, Adam C. Emerson wrote: >>> On 21/01/2017, Loic Dachary wrote: >>> [snip] >>>> The beginning of the next ceph release cycle seems like a good time >>>> to initiate that effort. If someone is willing to help with the >>>> bootstrap, now is a good time. The library will be hosted under the >>>> libcrush.org domain name. But that's about the only thing that >>>> happened so far :-) >>> >>> Would the Ceph git repository continue to have its own version of >>> CRUSH included, or would we pull in libcrush as a submodule? >> >> If all goes well and libcrush becomes actively and reliably maintained outside of the Ceph tree, it could either be a submodule or even a packaged dependency. Before that happens things can stay the way they are. I volunteer to manually monitor and cherry-pick whatever changes in the Ceph tree onto the standalone repository ( http://libcrush.org/main/libcrush/ ) so that it does not drift away. >> >>> Also, does this affect the relationship between userspace CRUSH and >>> Linux kernel CRUSH? >> >> I don't know :-) Unless I'm mistaken the code in the linux kernel is an unmodified copy of the code from src/crush/*.[ch]. > > Correct. libcrush won't impact the kernel in any way, as long as the > C core <-> C++ wrappers boundary stays intact, which it should ;) Yeah :-) Just rephrasing so I'm sure I understand you correctly: the important thing is that the C API stays as it is (functions & structs & constants) and that the semantic of each function is backward compatible. As long as it holds true, the kernel integration is going to be ok. > Some documentation will probably need to be added to cover things like > basic kernel compatibility (no floating point, stubs for asserts, etc) > and coding style for the C bits. Ack. > The core algorithm is far from where > libcrush initial activities would be centered though, I imagine. Indeed, more documentation & packaging right now. >> I however have no clue how it is tested to work as it should in both contexts. Other than running integration tests with teuthology. >> >> How do you suggest we go about it ? > > I don't think we need anything special here. When something changes in the .[ch] files, how do you ensure it's not breaking something ? Cheers -- Loïc Dachary, Artisan Logiciel Libre -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
