| Message ID | 20190306214226.14598-1-tobin@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | lib/string: Add strscpy_pad() function | expand |
On Thu, Mar 07, 2019 at 08:42:19AM +1100, Tobin C. Harding wrote:
> Hi,
Man, I didn't see the merge window was open, I thought rc8 only came out
on Sunday.
Sorry, please ignore this. Will re-send again later in the cycle.
thanks,
Tobin.
On Thu, Mar 07, 2019 at 08:49:34AM +1100, Tobin C. Harding wrote: > On Thu, Mar 07, 2019 at 08:42:19AM +1100, Tobin C. Harding wrote: > > Hi, > > Man, I didn't see the merge window was open, I thought rc8 only came out > on Sunday. > > Sorry, please ignore this. Will re-send again later in the cycle. Multiple people have suggested to me (offlist) that it is fine to go right ahead and send patches whenever. Shuah, do you take patches to kselftest at any stage of the dev cycle? Kees, same question please? thanks, Tobin.
On Thu, Mar 7, 2019 at 1:19 PM Tobin C. Harding <me@tobin.cc> wrote: > > On Thu, Mar 07, 2019 at 08:49:34AM +1100, Tobin C. Harding wrote: > > On Thu, Mar 07, 2019 at 08:42:19AM +1100, Tobin C. Harding wrote: > > > Hi, > > > > Man, I didn't see the merge window was open, I thought rc8 only came out > > on Sunday. > > > > Sorry, please ignore this. Will re-send again later in the cycle. > > Multiple people have suggested to me (offlist) that it is fine to go > right ahead and send patches whenever. > > Shuah, do you take patches to kselftest at any stage of the dev cycle? > > Kees, same question please? I don't official "close" my tree, but I'm certainly less likely to respond in a timeline manner near the merge window. ;) (And as a result, I haven't had a chance to look these over yet.)
On Thu, Mar 07, 2019 at 02:43:57PM -0800, Kees Cook wrote: > On Thu, Mar 7, 2019 at 1:19 PM Tobin C. Harding <me@tobin.cc> wrote: > > > > On Thu, Mar 07, 2019 at 08:49:34AM +1100, Tobin C. Harding wrote: > > > On Thu, Mar 07, 2019 at 08:42:19AM +1100, Tobin C. Harding wrote: > > > > Hi, > > > > > > Man, I didn't see the merge window was open, I thought rc8 only came out > > > on Sunday. > > > > > > Sorry, please ignore this. Will re-send again later in the cycle. > > > > Multiple people have suggested to me (offlist) that it is fine to go > > right ahead and send patches whenever. > > > > Shuah, do you take patches to kselftest at any stage of the dev cycle? > > > > Kees, same question please? > > I don't official "close" my tree, but I'm certainly less likely to > respond in a timeline manner near the merge window. ;) (And as a > result, I haven't had a chance to look these over yet.) Two weeks and I'm throwing eggs at your house. Tobin
On Thu, Mar 7, 2019 at 9:24 PM Tobin C. Harding <me@tobin.cc> wrote:
> Two weeks and I'm throwing eggs at your house.
If you can gets eggs from there to here I have a whole new
international shipping business proposition for you. :)
On Wed, Mar 6, 2019 at 1:43 PM Tobin C. Harding <tobin@kernel.org> wrote: > This set makes an attempt at adding a framework to kselftest for writing > kernel test modules. It also adds a script for use in creating script > test runners for kselftest. My macro-foo is not great, all criticism > and suggestions very much appreciated. The design is based on test > modules lib/test_printf.c, lib/test_bitmap.c, lib/test_xarray.c. Hi Shuah, The bulk of this series is in the kselftests. Would you be willing to carry this series? I think it might be able to use a v4 just to clean up the script-finding logic, but I might be entirely missing something about the best way to do it. Thanks! -Kees
On Tue, Apr 02, 2019 at 02:37:57PM -0700, Kees Cook wrote: > On Wed, Mar 6, 2019 at 1:43 PM Tobin C. Harding <tobin@kernel.org> wrote: > > This set makes an attempt at adding a framework to kselftest for writing > > kernel test modules. It also adds a script for use in creating script > > test runners for kselftest. My macro-foo is not great, all criticism > > and suggestions very much appreciated. The design is based on test > > modules lib/test_printf.c, lib/test_bitmap.c, lib/test_xarray.c. > > Hi Shuah, > > The bulk of this series is in the kselftests. Would you be willing to > carry this series? > > I think it might be able to use a v4 just to clean up the > script-finding logic, but I might be entirely missing something about > the best way to do it. v4 to come once I grok the bash stuff you suggested in 'PATCH v3.1'. thanks, Tobin.
On 4/2/19 6:25 PM, Tobin C. Harding wrote: > On Tue, Apr 02, 2019 at 02:37:57PM -0700, Kees Cook wrote: >> On Wed, Mar 6, 2019 at 1:43 PM Tobin C. Harding <tobin@kernel.org> wrote: >>> This set makes an attempt at adding a framework to kselftest for writing >>> kernel test modules. It also adds a script for use in creating script >>> test runners for kselftest. My macro-foo is not great, all criticism >>> and suggestions very much appreciated. The design is based on test >>> modules lib/test_printf.c, lib/test_bitmap.c, lib/test_xarray.c. >> >> Hi Shuah, >> >> The bulk of this series is in the kselftests. Would you be willing to >> carry this series? >> >> I think it might be able to use a v4 just to clean up the >> script-finding logic, but I might be entirely missing something about >> the best way to do it. > > v4 to come once I grok the bash stuff you suggested in 'PATCH v3.1'. > Yes I can take care of these. Will wait for v4 thanks, -- Shuah
Hi, strscpy_pad() patch set now with added test shenanigans. This version adds 5 initial patches to the set and splits the single patch from v2 into two separate patches (6 and 7). While doing the testing for strscpy_pad() it was noticed that there is duplication in how test modules are being fed to kselftest and also in the test modules themselves. This set makes an attempt at adding a framework to kselftest for writing kernel test modules. It also adds a script for use in creating script test runners for kselftest. My macro-foo is not great, all criticism and suggestions very much appreciated. The design is based on test modules lib/test_printf.c, lib/test_bitmap.c, lib/test_xarray.c. Shua, I'm by no means a kselftest expert, if this approach does not fit in with your general direction please say so. Kees, I put the strscpy_pad() addition patch separate so if this goes in through Shua's tree (and if it goes in at all) its a single patch to grab if we want to start playing around with strscpy_pad(). Patch 1 fixes module unload for lib/test_printf in preparation for the rest of the series. Patch 2 Adds a shell script that can be used to create shell script test runners. Patch 3 Converts current shell script runners in tools/testing/selftests/lib/ to use the script introduced in patch 2. Patch 4 Adds the test framework by way of a header file (inc. documentation) Patch 5 Converts a couple of current test modules to make some use of the newly added test framework. Patch 6 Adds strscpy_pad() Patch 7 Adds test module for strscpy_pad() using the new framework and script. If you are a testing geek and you would like to play with this; if you are already running a kernel built recently from your tree you may want to just apply the first 5 patches then you don't need to build/boot a new kernel, just config and build the lib/ test modules (test_printf etc.) and then: sudo make TARGETS=lib kselftest Late in the development of this I found that a bunch of boiler plate had to be added to the script to handle running tests with: make O=/path/to/kout kselftest The reason is that during the build we are in the output directory but the script is in the source directory. I get the feeling that a better understanding of how the kernel build process works would provide a better solution to this. The current solution is disappointing since removing duplication and boiler plate was the point of the whole exercise. I'd love a better way to solve this? One final interesting note: there are 36 test modules in lib/ only 3 of them are run by kselftest from tools/testing/selfests/lib? Thanks for looking at this, Tobin. Tobin C. Harding (7): lib/test_printf: Add empty module_exit function kselftest: Add test runner creation script kselftest/lib: Use new shell runner to define tests kselftest: Add test module framework header lib: Use new kselftest header lib/string: Add strscpy_pad() function lib: Add test module for strscpy_pad Documentation/dev-tools/kselftest.rst | 108 ++++++++++++- include/linux/string.h | 4 + lib/Kconfig.debug | 3 + lib/Makefile | 1 + lib/string.c | 47 +++++- lib/test_bitmap.c | 20 +-- lib/test_printf.c | 17 +-- lib/test_strscpy.c | 150 +++++++++++++++++++ tools/testing/selftests/kselftest_module.h | 48 ++++++ tools/testing/selftests/kselftest_module.sh | 75 ++++++++++ tools/testing/selftests/lib/Makefile | 2 +- tools/testing/selftests/lib/bitmap.sh | 25 ++-- tools/testing/selftests/lib/config | 1 + tools/testing/selftests/lib/prime_numbers.sh | 23 ++- tools/testing/selftests/lib/printf.sh | 25 ++-- tools/testing/selftests/lib/strscpy.sh | 17 +++ 16 files changed, 490 insertions(+), 76 deletions(-) create mode 100644 lib/test_strscpy.c create mode 100644 tools/testing/selftests/kselftest_module.h create mode 100755 tools/testing/selftests/kselftest_module.sh create mode 100755 tools/testing/selftests/lib/strscpy.sh