[no subject]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



So yes, on NIPA, we are safe.

But someone could run these packetdrill tests on a test machine
manually, then switch to something else and have unexpected behaviours.

> These three initial tests share set_defaults.sh, so in practice this
> should be fine. Most importantly, not affecting any tests outside
> net/packetdrill.
> 
> But agreed that netns are needed before adding more.
> 
> The unshare approach sounds fine to me. Easier than to plumb a Makefile
> variable through to the standalone run_kselftest.sh.

Yes, easier indeed.

>>>  3  give up on target proliferation; on a quick count we have 15 targets
>>>     in ksft for various bits of networking, faaar more than anyone else
>>>    + fewer targets limits the need for libraries, libraries local to
>>>      the target are trivial to handle
>>>    - ksft has no other form of "grouping" tests, if we collapse into 
>>>      a small number of targets it will be hard to run a group of tests
>>
>> It is good to have targets, to easily run a group of tests related to a
>> modification that has just been done, and to limit the size of the
>> required kernel config, etc. Probably easier to have different libs per
>> target/subsystem, and when something can be re-used elsewhere, it can be
>> extracted to a more generic lib maybe?
> 
> The conflicting CONFIGs between targets could be an issue. Even with
> packetdrill I had to check HZ and saw a difference with net/bpf.

If some kernel configs are conflicting, it might be needed to add a
check in ksft_runner.sh, because I know some CIs like LKFT build the
kernel once mixing different kernel config files, then run the different
targets on different VMs.

But maybe it is not needed to consider this case, and just adding
CONFIG_HZ_100=y in the config file is enough.

> That said, there could probably be a way to select tests between
> -c (collection/target) and -t (individual test) that uses a wildcard.

There are probably too many ways to run the selftests: personally, I
never use run_kselftest.sh. Either I use 'make run_tests' to run all
tests, or, when I need to check one specific selftest, I often directly
execute the script manually, instead of dealing with the kselftest
infrastructure. In this case, I can also simply use a for-loop using a
wildcard in bash to execute all the tests I want.

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.





[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux