On Wed, Mar 29, 2017 at 1:49 PM, Jeff Moyer <[email protected]> wrote:
> Dan Williams <[email protected]> writes:
>
>> On Wed, Mar 29, 2017 at 1:19 PM, Jeff Moyer <[email protected]> wrote:
>>> Dan Williams <[email protected]> writes:
>>>
>>>> On Wed, Mar 29, 2017 at 1:02 PM, Jeff Moyer <[email protected]> wrote:
>>>>> Dan Williams <[email protected]> writes:
>>>>>
>>>>>> +check_min_kver()
>>>>>> +{
>>>>>> +     local ver="$1"
>>>>>> +     : "${KVER:=$(uname -r)}"
>>>>>> +
>>>>>> +     [ -n "$ver" ] || return 1
>>>>>> +     [[ "$ver" == "$(echo -e "$ver\n$KVER" | sort -V | head -1)" ]]
>>>>>> +}
>>>>>> +
>>>>>> +check_min_kver "4.11" || { echo "kernel $KVER may lack latest 
>>>>>> device-dax fixes"; exit $rc; }
>>>>>
>>>>> Can we stop with this kernel version checking, please?  Test to see if
>>>>> you can create a device dax instance.  If not, skip the test.  If so,
>>>>> and if you have a kernel that isn't fixed, so be it, you'll get
>>>>> failures.
>>>>
>>>> I'd rather not. It helps me keep track of what went in where. If you
>>>> want to run all the tests on a random kernel just do:
>>>>
>>>>     KVER="4.11.0" make check
>>>
>>> This, of course, breaks completely with distro kernels.
>>
>> Why does this break distro kernels? The KVER variable overrides "uname -r"
>
> Because some features may not exist in the distro kernels.  It's the
> same problem you outline with xfstests, below.
>

Right, but you started off with suggesting that just running the test
and failing was ok, and that's the behavior you get with KVER=.

>>> You don't see this kind of checking in xfstests, for example.  git
>>> helps you keep track of what changes went in where (see git describe
>>> --contains).  It's weird to track that via your test harness.  So, I
>>> would definitely prefer to move to a model where we check for
>>> features instead of kernel versions.
>>
>> I see this as a deficiency of xfstests. We have had to go through and
>> qualify and track each xfstest and why it may fail with random
>> combinations of kernel, xfsprogs, or e2fsprogs versions. I'd much
>> prefer that upstream xfstests track the minimum versions of components
>> to make a given test pass so we can stop doing it out of tree.
>
> Yes, that's a good point.  I can't think of a good compromise, either.

Maybe we can at least get our annotated blacklist upstream so other
people can start contributing to it?
_______________________________________________
Linux-nvdimm mailing list
[email protected]
https://lists.01.org/mailman/listinfo/linux-nvdimm

Reply via email to