[v3,0/7] lib/string: Add strscpy_pad() function
mbox series

Message ID 20190306214226.14598-1-tobin@kernel.org
Headers show
Series
  • lib/string: Add strscpy_pad() function
Related show

Message

Tobin C. Harding March 6, 2019, 9:42 p.m. UTC
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

Comments

Tobin C. Harding March 6, 2019, 9:49 p.m. UTC | #1
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.
Tobin C. Harding March 7, 2019, 9:18 p.m. UTC | #2
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.
Kees Cook March 7, 2019, 10:43 p.m. UTC | #3
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.)
Tobin C. Harding March 8, 2019, 5:23 a.m. UTC | #4
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
Kees Cook March 8, 2019, 4:18 p.m. UTC | #5
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. :)
Kees Cook April 2, 2019, 9:37 p.m. UTC | #6
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
Tobin C. Harding April 3, 2019, 12:25 a.m. UTC | #7
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.
shuah April 3, 2019, 12:29 a.m. UTC | #8
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