On Mon, Jan 23, 2017 at 9:08 PM, Loic Dachary <loic@xxxxxxxxxxx> wrote: > 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. Well, that's a bit too strict. Ideally, we need to able to cut and-paste these files into the kernel with no or little effort. The API can change -- it just needs to be possible to bring the changes over to the kernel client. > >> 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 ? Run the k* test suites, mostly. For invasive changes (like a new tunable), instrument the kernel to dump the crushtool --show-mappings output to the console and compare it with the .t, but that's a manual process that requires writing some code. Such changes happen around twice a year, so it hasn't been a problem. Thanks, Ilya -- 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
