On Thu, Mar 21, 2019 at 3:27 PM Logan Gunthorpe logang@deltatee.com wrote:
On 2019-03-21 4:07 p.m., Brendan Higgins wrote:
A couple of points, as for needing CONFIG_PCI; my plan to deal with that type of thing has been that we would add support for a KUnit/UML version that is just for KUnit. It would mock out the necessary bits to provide a fake hardware implementation for anything that might depend on it. I wrote a prototype for mocking/faking MMIO that I presented to the list here[1]; it is not part of the current patchset because we decided it would be best to focus on getting an MVP in, but I plan on bringing it back up at some point. Anyway, what do you generally think of this approach?
Yes, I was wondering if that might be possible. I think that's a great approach but it will unfortunately take a lot of work before larger swaths of the kernel are testable in Kunit with UML. Having more common mocked infrastructure will be great by-product of it though.
Yeah, it's unfortunate that the best way to do something often takes so much longer.
Awesome, I looked at the code you posted and it doesn't look like you have had too many troubles. One thing that stood out to me, why did you need to put it in the kunit/ dir?
Yeah, writing the code was super easy. Only after, did I realized I couldn't get it to easily build.
Yeah, we really need to fix that; unfortunately, broadly addressing that problem is really hard and will most likely take a long time.
Putting it in the kunit directory was necessary because nothing in the NTB tree builds unless CONFIG_NTB is set (see drivers/Makefile) and CONFIG_NTB depends on CONFIG_PCI. I didn't experiment to see how hard it would be to set CONFIG_NTB without CONFIG_PCI; I assumed it would be tricky.
I am looking forward to see what you think!
Generally, I'm impressed and want to see this work in upstream as soon as possible so I can start to make use of it!
Great to hear! I was trying to get the next revision out this week, but addressing some of the comments is taking a little longer than expected. I should have something together fairly soon though (hopefully next week). Good news is that next revision will be non-RFC; most of the feedback has settled down and I think we are ready to start figuring out how to merge it. Fingers crossed :-)
Cheers