[Lustre-devel] [wc-discuss] Important changes to libcfs primitives usage.

[Ken Hornstein]

>Yes, we'd discussed this in the past, but the patches for lock cleanup
>never got added into the core Lustre code. We will still be the
>maintainers of the Lustre code in the kernel, so if there are innocuous
>no-op calls that can be put into the code (e.g. spin_lock_free()) or
>something similar I think that is fine.

Well as long as that's not a problem, I don't think that will be an issue
then.

>The root of the problem, for which there was no easy solution (wrappers
>or not) is that there is no easy way to test for this under Linux, so
>without either static code analysis tools (preferably run with the
>prepare-commit-msg git hook), or rigorous testing on MacOS, it would
>always be a game of catch up for these cleanups.

I understand that, and I'm personally fine with that.  From my memory,
the issue is not that a lot of lock structures were being created all
of the time and then deallocated (or I was able to find all of those
cases); it was more that a bunch of locks were leaked when Lustre shut
down.  I understand it's going to be a constant catch-up.

>I'd like to understand your reasons for thinking it is a bad idea. There
>are definite plusses and minuses to being in the kernel, but if there is
>some overwhelming badness for being in the kernel is like to know about
>it.

Well, fundamentally it just seems to me that you're tying your product
to the whims of a group of people who, quite frankly, don't care about
your product (except in a very abstract sense).  Giving away a huge amount
of control of your product looks like a bad idea to me.

But that's sort of vague; let me talk about specifics.  There's a HUGE
difference in practice between "feature X appears in Linux kernel
version Y" and "My RedHat release Z has a particular feature".  That's
where life gets complicated.  Many times we're stuck on a particular
kernel for various complicated reasons, yet we need to upgrade Lustre
... or vice versa.  It's kind of like Infiniband in the Linux kernel ...
at best, it doesn't hurt us, but it's always the "wrong" version (or so
my Infiniband guys tell me).  We never end up using the Infiniband in
the kernel, and sometimes (depending on the vagarities of the distro)
that screws us up hard; part of that is because for a long time one
particular distro never would distribute the development symbols for
the Infiniband in the kernel that matched what the kernel was running.
That won't be an issue with Lustre, but you get the idea.

--Ken