linux-kselftest.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
       [not found] <be8059f4-8e8f-cd18-0978-a9c861f6396b@linuxfoundation.org>
@ 2019-09-20 16:17 ` Linus Torvalds
  2019-09-20 16:26   ` Randy Dunlap
       [not found]   ` <CAKRRn-edxk9Du70A27V=d3Na73fh=fVvGEVsQRGROrQm05YRrA@mail.gmail.com>
  0 siblings, 2 replies; 23+ messages in thread
From: Linus Torvalds @ 2019-09-20 16:17 UTC (permalink / raw)
  To: Shuah Khan
  Cc: Mark Brown, Jarkko Sakkinen, Brendan Higgins, Anders Roxell,
	open list:KERNEL SELFTEST FRAMEWORK, Linux Kernel Mailing List

On Tue, Sep 17, 2019 at 12:26 PM Shuah Khan <skhan@linuxfoundation.org> wrote:
>
> This Kselftest update for Linux 5.4-rc1 consists of several fixes to
> existing tests and adds KUnit, a lightweight unit testing and mocking
> framework for the Linux kernel from Brendan Higgins.

So I pulled this, but then I almost immediately unpulled it.

My reason for doing that may be odd, but it's because of the top-level
'kunit' directory. This shouldn't be on the top level.

The reason I react so strongly is that it actually breaks my finger
memory. I don't type out filenames - I auto-compete them. So "kernel/"
is "k<tab>", "drivers/" is "d<tab>" etc.

It already doesn't work for everything ("mm/" is actually "mm<tab>"
not because we have files in the git tree, but because the build
creates various "module" files), but this breaks a common pattern for
me.

> In the future KUnit will be linked to Kselftest framework to provide
> a way to trigger KUnit tests from user-space.

Can the kernel parts please move to lib/kunit/ or something like that?

               Linus

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
  2019-09-20 16:17 ` [GIT PULL] Kselftest update for Linux 5.4-rc1 Linus Torvalds
@ 2019-09-20 16:26   ` Randy Dunlap
       [not found]   ` <CAKRRn-edxk9Du70A27V=d3Na73fh=fVvGEVsQRGROrQm05YRrA@mail.gmail.com>
  1 sibling, 0 replies; 23+ messages in thread
From: Randy Dunlap @ 2019-09-20 16:26 UTC (permalink / raw)
  To: Linus Torvalds, Shuah Khan
  Cc: Mark Brown, Jarkko Sakkinen, Brendan Higgins, Anders Roxell,
	open list:KERNEL SELFTEST FRAMEWORK, Linux Kernel Mailing List

On 9/20/19 9:17 AM, Linus Torvalds wrote:
> On Tue, Sep 17, 2019 at 12:26 PM Shuah Khan <skhan@linuxfoundation.org> wrote:
>>
>> This Kselftest update for Linux 5.4-rc1 consists of several fixes to
>> existing tests and adds KUnit, a lightweight unit testing and mocking
>> framework for the Linux kernel from Brendan Higgins.
> 
> So I pulled this, but then I almost immediately unpulled it.
> 
> My reason for doing that may be odd, but it's because of the top-level
> 'kunit' directory. This shouldn't be on the top level.
> 
> The reason I react so strongly is that it actually breaks my finger
> memory. I don't type out filenames - I auto-compete them. So "kernel/"
> is "k<tab>", "drivers/" is "d<tab>" etc.
> 
> It already doesn't work for everything ("mm/" is actually "mm<tab>"
> not because we have files in the git tree, but because the build
> creates various "module" files), but this breaks a common pattern for
> me.
> 
>> In the future KUnit will be linked to Kselftest framework to provide
>> a way to trigger KUnit tests from user-space.
> 
> Can the kernel parts please move to lib/kunit/ or something like that?

Please also move the top-level Kconfig menu item "KUnit support" to
somewhere that is not top-level.  Maybe also in the lib/ menu.  Maybe
in lib/Kconfig.debug.


-- 
~Randy

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
       [not found]   ` <CAKRRn-edxk9Du70A27V=d3Na73fh=fVvGEVsQRGROrQm05YRrA@mail.gmail.com>
@ 2019-09-20 16:35     ` Brendan Higgins
  2019-09-20 16:51       ` Linus Torvalds
  0 siblings, 1 reply; 23+ messages in thread
From: Brendan Higgins @ 2019-09-20 16:35 UTC (permalink / raw)
  To: Shuah Khan
  Cc: Linus Torvalds, Mark Brown, Jarkko Sakkinen, Anders Roxell,
	open list:KERNEL SELFTEST FRAMEWORK, Linux Kernel Mailing List

On Fri, Sep 20, 2019 at 9:27 AM Shuah Khan <skhan@linuxfoundation.org> wrote:
>
> Hi Linus,
>
> On Fri, Sep 20, 2019, 10:18 AM Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>
>> On Tue, Sep 17, 2019 at 12:26 PM Shuah Khan <skhan@linuxfoundation.org> wrote:
>> >
>> > This Kselftest update for Linux 5.4-rc1 consists of several fixes to
>> > existing tests and adds KUnit, a lightweight unit testing and mocking
>> > framework for the Linux kernel from Brendan Higgins.
>>
>> So I pulled this, but then I almost immediately unpulled it.
>>
>> My reason for doing that may be odd, but it's because of the top-level
>> 'kunit' directory. This shouldn't be on the top level.
>>
>> The reason I react so strongly is that it actually breaks my finger
>> memory. I don't type out filenames - I auto-compete them. So "kernel/"
>> is "k<tab>", "drivers/" is "d<tab>" etc.
>>
>> It already doesn't work for everything ("mm/" is actually "mm<tab>"
>> not because we have files in the git tree, but because the build
>> creates various "module" files), but this breaks a common pattern for
>> me.

Sorry about that. I am surprised that none of the other reviewers
brought this up.

> On hindsight, I probably should have run this by you to get your feedback.
>
>> > In the future KUnit will be linked to Kselftest framework to provide
>> > a way to trigger KUnit tests from user-space.
>>
>> Can the kernel parts please move to lib/kunit/ or something like that.

I'm fine with lib/kunit/.

> I will work with Brendan and come up with a plan and send another request early next week.

Cheers

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
  2019-09-20 16:35     ` Brendan Higgins
@ 2019-09-20 16:51       ` Linus Torvalds
  2019-09-20 18:03         ` Brendan Higgins
                           ` (2 more replies)
  0 siblings, 3 replies; 23+ messages in thread
From: Linus Torvalds @ 2019-09-20 16:51 UTC (permalink / raw)
  To: Brendan Higgins
  Cc: Shuah Khan, Mark Brown, Jarkko Sakkinen, Anders Roxell,
	open list:KERNEL SELFTEST FRAMEWORK, Linux Kernel Mailing List

On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins
<brendanhiggins@google.com> wrote:
>
> Sorry about that. I am surprised that none of the other reviewers
> brought this up.

I think I'm "special".

There was some other similar change a few years ago, which I
absolutely hated because of how it broke autocomplete for me. Very few
other people seemed to react to it.

Part of it may be that the kernel is almost the _only_ project I work
with, so unlike a lot of other developers, I end up having muscle
memory for kernel-specific issues.

Auto-completion was also one of the (many) reasons why I hated CVS -
having that annoying "CVS" directory there just always annoyed me.
There's a reason why git uses a dot-file.

So I just have issues that perhaps other people don't react to as
much. And aggressive tab-completion happens to be a thing for me.

               Linus

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
  2019-09-20 16:51       ` Linus Torvalds
@ 2019-09-20 18:03         ` Brendan Higgins
  2019-09-20 18:14           ` Linus Torvalds
  2019-09-20 18:06         ` Shuah Khan
  2019-09-22 11:25         ` Ingo Molnar
  2 siblings, 1 reply; 23+ messages in thread
From: Brendan Higgins @ 2019-09-20 18:03 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Shuah Khan, Mark Brown, Jarkko Sakkinen, Anders Roxell,
	open list:KERNEL SELFTEST FRAMEWORK, Linux Kernel Mailing List

On Fri, Sep 20, 2019 at 9:51 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins
> <brendanhiggins@google.com> wrote:
> >
> > Sorry about that. I am surprised that none of the other reviewers
> > brought this up.
>
> I think I'm "special".

Heh.

> There was some other similar change a few years ago, which I
> absolutely hated because of how it broke autocomplete for me. Very few
> other people seemed to react to it.

Well, it's good to know I'm not the first. :-)

> Part of it may be that the kernel is almost the _only_ project I work
> with, so unlike a lot of other developers, I end up having muscle
> memory for kernel-specific issues.
>
> Auto-completion was also one of the (many) reasons why I hated CVS -
> having that annoying "CVS" directory there just always annoyed me.
> There's a reason why git uses a dot-file.

Yuck. I have never used CVS myself, but the dot-file approach seems
much more natural to me. Then again, I have been using git pretty much
since I first started programming, so it's hard to say that I am not
biased.

> So I just have issues that perhaps other people don't react to as
> much. And aggressive tab-completion happens to be a thing for me.

Fair enough. On that note, are you okay with the `include/kunit/`
directory, or do you want me to move it to `include/linux/kunit`?

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
  2019-09-20 16:51       ` Linus Torvalds
  2019-09-20 18:03         ` Brendan Higgins
@ 2019-09-20 18:06         ` Shuah Khan
  2019-09-22 11:25         ` Ingo Molnar
  2 siblings, 0 replies; 23+ messages in thread
From: Shuah Khan @ 2019-09-20 18:06 UTC (permalink / raw)
  To: Linus Torvalds, Brendan Higgins
  Cc: Mark Brown, Jarkko Sakkinen, Anders Roxell,
	open list:KERNEL SELFTEST FRAMEWORK, Linux Kernel Mailing List,
	Shuah Khan

On 9/20/19 10:51 AM, Linus Torvalds wrote:
> On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins
> <brendanhiggins@google.com> wrote:
>>
>> Sorry about that. I am surprised that none of the other reviewers
>> brought this up.
> 
> I think I'm "special".
> 
> There was some other similar change a few years ago, which I
> absolutely hated because of how it broke autocomplete for me. Very few
> other people seemed to react to it.
> 
> Part of it may be that the kernel is almost the _only_ project I work
> with, so unlike a lot of other developers, I end up having muscle
> memory for kernel-specific issues.
> 
> Auto-completion was also one of the (many) reasons why I hated CVS -
> having that annoying "CVS" directory there just always annoyed me.
> There's a reason why git uses a dot-file.
> 
> So I just have issues that perhaps other people don't react to as
> much. And aggressive tab-completion happens to be a thing for me.
> 

Thanks for explaining. Brendan and I will get this sorted out.

Looks like my previous response didn't make it to the kselftest
and kernel lists.

thanks,
-- Shuah


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
  2019-09-20 18:03         ` Brendan Higgins
@ 2019-09-20 18:14           ` Linus Torvalds
  2019-09-20 18:16             ` Brendan Higgins
  0 siblings, 1 reply; 23+ messages in thread
From: Linus Torvalds @ 2019-09-20 18:14 UTC (permalink / raw)
  To: Brendan Higgins
  Cc: Shuah Khan, Mark Brown, Jarkko Sakkinen, Anders Roxell,
	open list:KERNEL SELFTEST FRAMEWORK, Linux Kernel Mailing List

On Fri, Sep 20, 2019 at 11:03 AM Brendan Higgins
<brendanhiggins@google.com> wrote:
>
> Fair enough. On that note, are you okay with the `include/kunit/`
> directory, or do you want me to move it to `include/linux/kunit`?

"include/kunit" should work just fine for me. At least I didn't react
to it immediately when I had done my test-pull, and it doesn't change
any auto-completion patterns for me either.

[ We already have two 'k' names under include, but even if that wasn't
true, I don't type those names anyway so I wouldn't have had
muscle-memory for those two directories in the first place.

  Under include, it's "linux" (and to a smaller extent "asm-generic")
that I autocomplete. ]

            Linus

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
  2019-09-20 18:14           ` Linus Torvalds
@ 2019-09-20 18:16             ` Brendan Higgins
  0 siblings, 0 replies; 23+ messages in thread
From: Brendan Higgins @ 2019-09-20 18:16 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Shuah Khan, Mark Brown, Jarkko Sakkinen, Anders Roxell,
	open list:KERNEL SELFTEST FRAMEWORK, Linux Kernel Mailing List

On Fri, Sep 20, 2019 at 11:15 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Fri, Sep 20, 2019 at 11:03 AM Brendan Higgins
> <brendanhiggins@google.com> wrote:
> >
> > Fair enough. On that note, are you okay with the `include/kunit/`
> > directory, or do you want me to move it to `include/linux/kunit`?
>
> "include/kunit" should work just fine for me. At least I didn't react
> to it immediately when I had done my test-pull, and it doesn't change
> any auto-completion patterns for me either.

Sounds good to me.

Thanks!

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
  2019-09-20 16:51       ` Linus Torvalds
  2019-09-20 18:03         ` Brendan Higgins
  2019-09-20 18:06         ` Shuah Khan
@ 2019-09-22 11:25         ` Ingo Molnar
  2019-09-22 11:52           ` Greg KH
                             ` (4 more replies)
  2 siblings, 5 replies; 23+ messages in thread
From: Ingo Molnar @ 2019-09-22 11:25 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Brendan Higgins, Shuah Khan, Mark Brown, Jarkko Sakkinen,
	Anders Roxell, open list:KERNEL SELFTEST FRAMEWORK,
	Linux Kernel Mailing List


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins
> <brendanhiggins@google.com> wrote:
> >
> > Sorry about that. I am surprised that none of the other reviewers
> > brought this up.
> 
> I think I'm "special".
> 
> There was some other similar change a few years ago, which I
> absolutely hated because of how it broke autocomplete for me. Very few
> other people seemed to react to it.

FWIW, I am obsessively sensitive to autocomplete and overall source code 
file hieararchy and nomenclature details as well, so it's not just you.

Beyond the muscle memory aspect, nonsensical naming and inanely flat file 
hierarchies annoy kernel developers and makes it harder for newbies to 
understand the kernel source as well.

The less clutter, the more organization, the better - and there's very 
few valid technical reasons to add any new files or directories to the 
top level directory - we should probably *remove* quite a few.

For example 'firmware/' was recently moved to drivers/firmware/, and in a 
similar fashion about a third of the remaining 22 directories should 
probably be moved too:

  drwxr-xr-x    arch
  drwxr-xr-x    block
  drwxr-xr-x    certs           # move to build/certs/ dir
  drwxr-xr-x    crypto          # move to kernel/crypto/ or security/crypto/
  drwxr-xr-x    Documentation
  drwxr-xr-x    drivers
  drwxr-xr-x    fs
  drwxr-xr-x    include
  drwxr-xr-x    init
  drwxr-xr-x    ipc             # move to kernel/ipc/
  drwxr-xr-x    kernel
  drwxr-xr-x    lib
  drwxr-xr-x    LICENSES
  drwxr-xr-x    mm
  drwxr-xr-x    net
  drwxr-xr-x    samples         # move to Documentation/samples/
  drwxr-xr-x    scripts         # move to build/scripts/
  drwxr-xr-x    security
  drwxr-xr-x    sound           # move to drivers/sound/
  drwxr-xr-x    tools
  drwxr-xr-x    usr             # move to build/usr/
  drwxr-xr-x    virt            # move to the already existing drivers/virt/

  -rw-r--r--    COPYING
  -rw-r--r--    CREDITS
  -rw-r--r--    Kbuild
  -rw-r--r--    Kconfig
  -rw-r--r--    MAINTAINERS
  -rw-r--r--    Makefile
  -rw-r--r--    README

There's a few borderline ones:

 - 'block' could in principle move to drivers/block/core/ but it's fine 
   at the top level too I think.

 - 'init' could in principle be moved to kernel/init/ - but it's not 
   wrong at the top level either.

The remaining top level hierarchy would look pretty sweet and short:

  drwxr-xr-x    arch
  drwxr-xr-x    block
  drwxr-xr-x    build             # new
  drwxr-xr-x    Documentation
  drwxr-xr-x    drivers
  drwxr-xr-x    fs
  drwxr-xr-x    include
  drwxr-xr-x    init
  drwxr-xr-x    kernel
  drwxr-xr-x    lib
  drwxr-xr-x    LICENSES
  drwxr-xr-x    mm
  drwxr-xr-x    net
  drwxr-xr-x    security
  drwxr-xr-x    tools

  -rw-r--r--    COPYING
  -rw-r--r--    CREDITS
  -rw-r--r--    Kbuild
  -rw-r--r--    Kconfig
  -rw-r--r--    MAINTAINERS
  -rw-r--r--    Makefile
  -rw-r--r--    README

I'm volunteering to do this (in a scripted, repeatable, reviewable, 
tweakable and "easy to execute in a quiet moment" fashion), although
I also expect you to balk at the churn. :-)

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
  2019-09-22 11:25         ` Ingo Molnar
@ 2019-09-22 11:52           ` Greg KH
  2019-09-23 14:44             ` Shuah Khan
  2019-09-23 23:54           ` Tim.Bird
                             ` (3 subsequent siblings)
  4 siblings, 1 reply; 23+ messages in thread
From: Greg KH @ 2019-09-22 11:52 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Linus Torvalds, Brendan Higgins, Shuah Khan, Mark Brown,
	Jarkko Sakkinen, Anders Roxell,
	open list:KERNEL SELFTEST FRAMEWORK, Linux Kernel Mailing List

On Sun, Sep 22, 2019 at 01:25:55PM +0200, Ingo Molnar wrote:
> 
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> > On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins
> > <brendanhiggins@google.com> wrote:
> > >
> > > Sorry about that. I am surprised that none of the other reviewers
> > > brought this up.
> > 
> > I think I'm "special".
> > 
> > There was some other similar change a few years ago, which I
> > absolutely hated because of how it broke autocomplete for me. Very few
> > other people seemed to react to it.
> 
> FWIW, I am obsessively sensitive to autocomplete and overall source code 
> file hieararchy and nomenclature details as well, so it's not just you.
> 
> Beyond the muscle memory aspect, nonsensical naming and inanely flat file 
> hierarchies annoy kernel developers and makes it harder for newbies to 
> understand the kernel source as well.
> 
> The less clutter, the more organization, the better - and there's very 
> few valid technical reasons to add any new files or directories to the 
> top level directory - we should probably *remove* quite a few.
> 
> For example 'firmware/' was recently moved to drivers/firmware/, and in a 
> similar fashion about a third of the remaining 22 directories should 
> probably be moved too:
> 
>   drwxr-xr-x    arch
>   drwxr-xr-x    block
>   drwxr-xr-x    certs           # move to build/certs/ dir
>   drwxr-xr-x    crypto          # move to kernel/crypto/ or security/crypto/
>   drwxr-xr-x    Documentation
>   drwxr-xr-x    drivers
>   drwxr-xr-x    fs
>   drwxr-xr-x    include
>   drwxr-xr-x    init
>   drwxr-xr-x    ipc             # move to kernel/ipc/
>   drwxr-xr-x    kernel
>   drwxr-xr-x    lib
>   drwxr-xr-x    LICENSES
>   drwxr-xr-x    mm
>   drwxr-xr-x    net
>   drwxr-xr-x    samples         # move to Documentation/samples/
>   drwxr-xr-x    scripts         # move to build/scripts/
>   drwxr-xr-x    security
>   drwxr-xr-x    sound           # move to drivers/sound/
>   drwxr-xr-x    tools
>   drwxr-xr-x    usr             # move to build/usr/
>   drwxr-xr-x    virt            # move to the already existing drivers/virt/
> 
>   -rw-r--r--    COPYING
>   -rw-r--r--    CREDITS
>   -rw-r--r--    Kbuild
>   -rw-r--r--    Kconfig
>   -rw-r--r--    MAINTAINERS
>   -rw-r--r--    Makefile
>   -rw-r--r--    README
> 
> There's a few borderline ones:
> 
>  - 'block' could in principle move to drivers/block/core/ but it's fine 
>    at the top level too I think.
> 
>  - 'init' could in principle be moved to kernel/init/ - but it's not 
>    wrong at the top level either.
> 
> The remaining top level hierarchy would look pretty sweet and short:
> 
>   drwxr-xr-x    arch
>   drwxr-xr-x    block
>   drwxr-xr-x    build             # new
>   drwxr-xr-x    Documentation
>   drwxr-xr-x    drivers
>   drwxr-xr-x    fs
>   drwxr-xr-x    include
>   drwxr-xr-x    init
>   drwxr-xr-x    kernel
>   drwxr-xr-x    lib
>   drwxr-xr-x    LICENSES
>   drwxr-xr-x    mm
>   drwxr-xr-x    net
>   drwxr-xr-x    security
>   drwxr-xr-x    tools
> 
>   -rw-r--r--    COPYING
>   -rw-r--r--    CREDITS
>   -rw-r--r--    Kbuild
>   -rw-r--r--    Kconfig
>   -rw-r--r--    MAINTAINERS
>   -rw-r--r--    Makefile
>   -rw-r--r--    README
> 
> I'm volunteering to do this (in a scripted, repeatable, reviewable, 
> tweakable and "easy to execute in a quiet moment" fashion), although
> I also expect you to balk at the churn. :-)

I for one would love the above changes.  And I'm the one that has to
deal with all of the backporting issues that arise with stable backports :)

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
  2019-09-22 11:52           ` Greg KH
@ 2019-09-23 14:44             ` Shuah Khan
  2019-09-23 19:43               ` Ingo Molnar
  0 siblings, 1 reply; 23+ messages in thread
From: Shuah Khan @ 2019-09-23 14:44 UTC (permalink / raw)
  To: Greg KH, Ingo Molnar
  Cc: Linus Torvalds, Brendan Higgins, Mark Brown, Jarkko Sakkinen,
	Anders Roxell, open list:KERNEL SELFTEST FRAMEWORK,
	Linux Kernel Mailing List, Shuah Khan

On 9/22/19 5:52 AM, Greg KH wrote:
> On Sun, Sep 22, 2019 at 01:25:55PM +0200, Ingo Molnar wrote:
>>
>> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>
>>> On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins
>>> <brendanhiggins@google.com> wrote:
>>>>
>>>> Sorry about that. I am surprised that none of the other reviewers
>>>> brought this up.
>>>
>>> I think I'm "special".
>>>
>>> There was some other similar change a few years ago, which I
>>> absolutely hated because of how it broke autocomplete for me. Very few
>>> other people seemed to react to it.
>>
>> FWIW, I am obsessively sensitive to autocomplete and overall source code
>> file hieararchy and nomenclature details as well, so it's not just you.
>>
>> Beyond the muscle memory aspect, nonsensical naming and inanely flat file
>> hierarchies annoy kernel developers and makes it harder for newbies to
>> understand the kernel source as well.
>>
>> The less clutter, the more organization, the better - and there's very
>> few valid technical reasons to add any new files or directories to the
>> top level directory - we should probably *remove* quite a few.
>>
>> For example 'firmware/' was recently moved to drivers/firmware/, and in a
>> similar fashion about a third of the remaining 22 directories should
>> probably be moved too:
>>
>>    drwxr-xr-x    arch
>>    drwxr-xr-x    block
>>    drwxr-xr-x    certs           # move to build/certs/ dir
>>    drwxr-xr-x    crypto          # move to kernel/crypto/ or security/crypto/
>>    drwxr-xr-x    Documentation
>>    drwxr-xr-x    drivers
>>    drwxr-xr-x    fs
>>    drwxr-xr-x    include
>>    drwxr-xr-x    init
>>    drwxr-xr-x    ipc             # move to kernel/ipc/
>>    drwxr-xr-x    kernel
>>    drwxr-xr-x    lib
>>    drwxr-xr-x    LICENSES
>>    drwxr-xr-x    mm
>>    drwxr-xr-x    net
>>    drwxr-xr-x    samples         # move to Documentation/samples/
>>    drwxr-xr-x    scripts         # move to build/scripts/
>>    drwxr-xr-x    security
>>    drwxr-xr-x    sound           # move to drivers/sound/
>>    drwxr-xr-x    tools
>>    drwxr-xr-x    usr             # move to build/usr/
>>    drwxr-xr-x    virt            # move to the already existing drivers/virt/
>>
>>    -rw-r--r--    COPYING
>>    -rw-r--r--    CREDITS
>>    -rw-r--r--    Kbuild
>>    -rw-r--r--    Kconfig
>>    -rw-r--r--    MAINTAINERS
>>    -rw-r--r--    Makefile
>>    -rw-r--r--    README
>>
>> There's a few borderline ones:
>>
>>   - 'block' could in principle move to drivers/block/core/ but it's fine
>>     at the top level too I think.
>>
>>   - 'init' could in principle be moved to kernel/init/ - but it's not
>>     wrong at the top level either.
>>
>> The remaining top level hierarchy would look pretty sweet and short:
>>
>>    drwxr-xr-x    arch
>>    drwxr-xr-x    block
>>    drwxr-xr-x    build             # new
>>    drwxr-xr-x    Documentation
>>    drwxr-xr-x    drivers
>>    drwxr-xr-x    fs
>>    drwxr-xr-x    include
>>    drwxr-xr-x    init
>>    drwxr-xr-x    kernel
>>    drwxr-xr-x    lib
>>    drwxr-xr-x    LICENSES
>>    drwxr-xr-x    mm
>>    drwxr-xr-x    net
>>    drwxr-xr-x    security
>>    drwxr-xr-x    tools
>>
>>    -rw-r--r--    COPYING
>>    -rw-r--r--    CREDITS
>>    -rw-r--r--    Kbuild
>>    -rw-r--r--    Kconfig
>>    -rw-r--r--    MAINTAINERS
>>    -rw-r--r--    Makefile
>>    -rw-r--r--    README
>>
>> I'm volunteering to do this (in a scripted, repeatable, reviewable,
>> tweakable and "easy to execute in a quiet moment" fashion), although
>> I also expect you to balk at the churn. :-)
> 
> I for one would love the above changes.  And I'm the one that has to
> deal with all of the backporting issues that arise with stable backports :)
> 

I am exploring the possibility to move selftests to a better location
or add a git alias so it can be found easily. With the addition of KUnit
and future work that is planned to connect kselftest and KUnit, it would
make sense have selftests to be in a location that is better suited than
where it currently resides.

I have been getting feedback from some developers that they would like
to see selftests more visible and easier to find.

There are some dependencies (unintended, shouldn't exist) between some
tests and content under tools that might pose some logistical problems,
in addition to the churn of backporting.

I haven't explored "git alias" yet though. Since this topic of moving
came up, I would liek to get feedback on selftests location in general
and where would be a good place for it.

thanks,
-- Shuah


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
  2019-09-23 14:44             ` Shuah Khan
@ 2019-09-23 19:43               ` Ingo Molnar
  2019-09-23 19:52                 ` Randy Dunlap
  0 siblings, 1 reply; 23+ messages in thread
From: Ingo Molnar @ 2019-09-23 19:43 UTC (permalink / raw)
  To: Shuah Khan
  Cc: Greg KH, Linus Torvalds, Brendan Higgins, Mark Brown,
	Jarkko Sakkinen, Anders Roxell,
	open list:KERNEL SELFTEST FRAMEWORK, Linux Kernel Mailing List


* Shuah Khan <skhan@linuxfoundation.org> wrote:

> I am exploring the possibility to move selftests to a better location 
> or add a git alias so it can be found easily. With the addition of 
> KUnit and future work that is planned to connect kselftest and KUnit, 
> it would make sense have selftests to be in a location that is better 
> suited than where it currently resides.
> 
> I have been getting feedback from some developers that they would like 
> to see selftests more visible and easier to find.
> 
> There are some dependencies (unintended, shouldn't exist) between some 
> tests and content under tools that might pose some logistical problems, 
> in addition to the churn of backporting.
> 
> I haven't explored "git alias" yet though. Since this topic of moving 
> came up, I would liek to get feedback on selftests location in general 
> and where would be a good place for it.

I'm not sure about the Git alias thing - but I do agree that 
tools/testing/selftests is a pretty obscure location given the importance 
of kernel unit tests - and I think it could be moved one level higher, to 
tools/selftests? The "selftest" name already implies the "test" aspect 
after all.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
  2019-09-23 19:43               ` Ingo Molnar
@ 2019-09-23 19:52                 ` Randy Dunlap
  2019-09-23 20:29                   ` Shuah Khan
  0 siblings, 1 reply; 23+ messages in thread
From: Randy Dunlap @ 2019-09-23 19:52 UTC (permalink / raw)
  To: Ingo Molnar, Shuah Khan
  Cc: Greg KH, Linus Torvalds, Brendan Higgins, Mark Brown,
	Jarkko Sakkinen, Anders Roxell,
	open list:KERNEL SELFTEST FRAMEWORK, Linux Kernel Mailing List

On 9/23/19 12:43 PM, Ingo Molnar wrote:
> 
> * Shuah Khan <skhan@linuxfoundation.org> wrote:
> 
>> I am exploring the possibility to move selftests to a better location 
>> or add a git alias so it can be found easily. With the addition of 
>> KUnit and future work that is planned to connect kselftest and KUnit, 
>> it would make sense have selftests to be in a location that is better 
>> suited than where it currently resides.
>>
>> I have been getting feedback from some developers that they would like 
>> to see selftests more visible and easier to find.
>>
>> There are some dependencies (unintended, shouldn't exist) between some 
>> tests and content under tools that might pose some logistical problems, 
>> in addition to the churn of backporting.
>>
>> I haven't explored "git alias" yet though. Since this topic of moving 
>> came up, I would liek to get feedback on selftests location in general 
>> and where would be a good place for it.
> 
> I'm not sure about the Git alias thing - but I do agree that 
> tools/testing/selftests is a pretty obscure location given the importance 
> of kernel unit tests - and I think it could be moved one level higher, to 
> tools/selftests? The "selftest" name already implies the "test" aspect 
> after all.


Without trying to use too much paint, I would move testing/ to a top-level
dir, outside of tools/, and leave selftest/ under testing/.

-- 
~Randy

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
  2019-09-23 19:52                 ` Randy Dunlap
@ 2019-09-23 20:29                   ` Shuah Khan
  2019-09-23 20:53                     ` Ingo Molnar
  0 siblings, 1 reply; 23+ messages in thread
From: Shuah Khan @ 2019-09-23 20:29 UTC (permalink / raw)
  To: Randy Dunlap, Ingo Molnar
  Cc: Greg KH, Linus Torvalds, Brendan Higgins, Mark Brown,
	Jarkko Sakkinen, Anders Roxell,
	open list:KERNEL SELFTEST FRAMEWORK, Linux Kernel Mailing List,
	Shuah Khan

On 9/23/19 1:52 PM, Randy Dunlap wrote:
> On 9/23/19 12:43 PM, Ingo Molnar wrote:
>>
>> * Shuah Khan <skhan@linuxfoundation.org> wrote:
>>
>>> I am exploring the possibility to move selftests to a better location
>>> or add a git alias so it can be found easily. With the addition of
>>> KUnit and future work that is planned to connect kselftest and KUnit,
>>> it would make sense have selftests to be in a location that is better
>>> suited than where it currently resides.
>>>
>>> I have been getting feedback from some developers that they would like
>>> to see selftests more visible and easier to find.
>>>
>>> There are some dependencies (unintended, shouldn't exist) between some
>>> tests and content under tools that might pose some logistical problems,
>>> in addition to the churn of backporting.
>>>
>>> I haven't explored "git alias" yet though. Since this topic of moving
>>> came up, I would liek to get feedback on selftests location in general
>>> and where would be a good place for it.
>>
>> I'm not sure about the Git alias thing - but I do agree that
>> tools/testing/selftests is a pretty obscure location given the importance
>> of kernel unit tests - and I think it could be moved one level higher, to
>> tools/selftests? The "selftest" name already implies the "test" aspect
>> after all.
> 
Right. Obscure location given the importance is the problem.

> 
> Without trying to use too much paint, I would move testing/ to a top-level
> dir, outside of tools/, and leave selftest/ under testing/.
> 

Right. What you suggesting is very similar to and more complete than
what I have been thinking about and proposed at the KS kselftest track.


i.e move tools/testing/selftests to kselftest at the root level. I like
your idea of moving tools/testing up to root and keep selftests under
it.

If we are good with this kind of change, I would like to get this done
sooner than later. There is some back-porting churn to worry about.

thanks,
-- Shuah

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
  2019-09-23 20:29                   ` Shuah Khan
@ 2019-09-23 20:53                     ` Ingo Molnar
  2019-09-23 21:11                       ` Shuah Khan
  0 siblings, 1 reply; 23+ messages in thread
From: Ingo Molnar @ 2019-09-23 20:53 UTC (permalink / raw)
  To: Shuah Khan
  Cc: Randy Dunlap, Greg KH, Linus Torvalds, Brendan Higgins,
	Mark Brown, Jarkko Sakkinen, Anders Roxell,
	open list:KERNEL SELFTEST FRAMEWORK, Linux Kernel Mailing List


* Shuah Khan <skhan@linuxfoundation.org> wrote:

> Right. What you suggesting is very similar to and more complete than 
> what I have been thinking about and proposed at the KS kselftest track.
> 
> i.e move tools/testing/selftests to kselftest at the root level. I like 
> your idea of moving tools/testing up to root and keep selftests under 
> it.
> 
> If we are good with this kind of change, I would like to get this done 
> sooner than later. There is some back-porting churn to worry about.

I think the movement I suggested would be sufficient:

  tools/testing/selftests/ =>  tools/selftests/

I.e. let's not clutter up the top level directory.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
  2019-09-23 20:53                     ` Ingo Molnar
@ 2019-09-23 21:11                       ` Shuah Khan
  0 siblings, 0 replies; 23+ messages in thread
From: Shuah Khan @ 2019-09-23 21:11 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Randy Dunlap, Greg KH, Linus Torvalds, Brendan Higgins,
	Mark Brown, Jarkko Sakkinen, Anders Roxell,
	open list:KERNEL SELFTEST FRAMEWORK, Linux Kernel Mailing List,
	Shuah Khan

On 9/23/19 2:53 PM, Ingo Molnar wrote:
> 
> * Shuah Khan <skhan@linuxfoundation.org> wrote:
> 
>> Right. What you suggesting is very similar to and more complete than
>> what I have been thinking about and proposed at the KS kselftest track.
>>
>> i.e move tools/testing/selftests to kselftest at the root level. I like
>> your idea of moving tools/testing up to root and keep selftests under
>> it.
>>
>> If we are good with this kind of change, I would like to get this done
>> sooner than later. There is some back-porting churn to worry about.
> 
> I think the movement I suggested would be sufficient:
> 
>    tools/testing/selftests/ =>  tools/selftests/
> 
> I.e. let's not clutter up the top level directory.
> 

Yeah good point.

-- Shuah


^ permalink raw reply	[flat|nested] 23+ messages in thread

* RE: [GIT PULL] Kselftest update for Linux 5.4-rc1
  2019-09-22 11:25         ` Ingo Molnar
  2019-09-22 11:52           ` Greg KH
@ 2019-09-23 23:54           ` Tim.Bird
  2019-09-24  8:07             ` Ingo Molnar
  2019-09-26 12:52           ` David Sterba
                             ` (2 subsequent siblings)
  4 siblings, 1 reply; 23+ messages in thread
From: Tim.Bird @ 2019-09-23 23:54 UTC (permalink / raw)
  To: mingo, torvalds
  Cc: brendanhiggins, skhan, broonie, jarkko.sakkinen, anders.roxell,
	linux-kselftest, linux-kernel

> -----Original Message-----
> From: Ingo Molnar on Sunday, September 22, 2019 1:26 AM
> 
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> > On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins
> > <brendanhiggins@google.com> wrote:
> > >
> > > Sorry about that. I am surprised that none of the other reviewers
> > > brought this up.
> >
> > I think I'm "special".
> >
> > There was some other similar change a few years ago, which I
> > absolutely hated because of how it broke autocomplete for me. Very few
> > other people seemed to react to it.
> 
> FWIW, I am obsessively sensitive to autocomplete and overall source code
> file hieararchy and nomenclature details as well, so it's not just you.
> 
> Beyond the muscle memory aspect, nonsensical naming and inanely flat file
> hierarchies annoy kernel developers and makes it harder for newbies to
> understand the kernel source as well.
> 
> The less clutter, the more organization, the better - and there's very
> few valid technical reasons to add any new files or directories to the
> top level directory - we should probably *remove* quite a few.
> 
> For example 'firmware/' was recently moved to drivers/firmware/, and in a
> similar fashion about a third of the remaining 22 directories should
> probably be moved too:
> 
>   drwxr-xr-x    arch
>   drwxr-xr-x    block
>   drwxr-xr-x    certs           # move to build/certs/ dir
>   drwxr-xr-x    crypto          # move to kernel/crypto/ or security/crypto/
>   drwxr-xr-x    Documentation
>   drwxr-xr-x    drivers
>   drwxr-xr-x    fs
>   drwxr-xr-x    include
>   drwxr-xr-x    init
>   drwxr-xr-x    ipc             # move to kernel/ipc/
>   drwxr-xr-x    kernel
>   drwxr-xr-x    lib
>   drwxr-xr-x    LICENSES
>   drwxr-xr-x    mm
>   drwxr-xr-x    net
>   drwxr-xr-x    samples         # move to Documentation/samples/
>   drwxr-xr-x    scripts         # move to build/scripts/

This one seems like it would break a lot of workflows, and contributor
muscle memory and scripts.  get_maintainer.pl and checkpatch.pl
are probably in quite a few people's scripts.

Also, I'm not sure '/build' is the right destination for this.  There
are a lot more things in there than just build scripts.  If you really
want to remove the top level 'scripts', it might be best to put
the  scripts from top-level '/scripts' into '/tools/scripts', which is
mostly empty now.
 -- Tim

... rest snipped ...

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
  2019-09-23 23:54           ` Tim.Bird
@ 2019-09-24  8:07             ` Ingo Molnar
  0 siblings, 0 replies; 23+ messages in thread
From: Ingo Molnar @ 2019-09-24  8:07 UTC (permalink / raw)
  To: Tim.Bird
  Cc: torvalds, brendanhiggins, skhan, broonie, jarkko.sakkinen,
	anders.roxell, linux-kselftest, linux-kernel


* Tim.Bird@sony.com <Tim.Bird@sony.com> wrote:

> > -----Original Message-----
> > From: Ingo Molnar on Sunday, September 22, 2019 1:26 AM
> > 
> > * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > 
> > > On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins
> > > <brendanhiggins@google.com> wrote:
> > > >
> > > > Sorry about that. I am surprised that none of the other reviewers
> > > > brought this up.
> > >
> > > I think I'm "special".
> > >
> > > There was some other similar change a few years ago, which I
> > > absolutely hated because of how it broke autocomplete for me. Very few
> > > other people seemed to react to it.
> > 
> > FWIW, I am obsessively sensitive to autocomplete and overall source code
> > file hieararchy and nomenclature details as well, so it's not just you.
> > 
> > Beyond the muscle memory aspect, nonsensical naming and inanely flat file
> > hierarchies annoy kernel developers and makes it harder for newbies to
> > understand the kernel source as well.
> > 
> > The less clutter, the more organization, the better - and there's very
> > few valid technical reasons to add any new files or directories to the
> > top level directory - we should probably *remove* quite a few.
> > 
> > For example 'firmware/' was recently moved to drivers/firmware/, and in a
> > similar fashion about a third of the remaining 22 directories should
> > probably be moved too:
> > 
> >   drwxr-xr-x    arch
> >   drwxr-xr-x    block
> >   drwxr-xr-x    certs           # move to build/certs/ dir
> >   drwxr-xr-x    crypto          # move to kernel/crypto/ or security/crypto/
> >   drwxr-xr-x    Documentation
> >   drwxr-xr-x    drivers
> >   drwxr-xr-x    fs
> >   drwxr-xr-x    include
> >   drwxr-xr-x    init
> >   drwxr-xr-x    ipc             # move to kernel/ipc/
> >   drwxr-xr-x    kernel
> >   drwxr-xr-x    lib
> >   drwxr-xr-x    LICENSES
> >   drwxr-xr-x    mm
> >   drwxr-xr-x    net
> >   drwxr-xr-x    samples         # move to Documentation/samples/
> >   drwxr-xr-x    scripts         # move to build/scripts/
> 
> This one seems like it would break a lot of workflows, and contributor
> muscle memory and scripts.  get_maintainer.pl and checkpatch.pl
> are probably in quite a few people's scripts.
> 
> Also, I'm not sure '/build' is the right destination for this.  There
> are a lot more things in there than just build scripts.  If you really
> want to remove the top level 'scripts', it might be best to put
> the  scripts from top-level '/scripts' into '/tools/scripts', which is
> mostly empty now.

Agreed - I'll leave it alone for now, because you are right that it's 
widely used.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
  2019-09-22 11:25         ` Ingo Molnar
  2019-09-22 11:52           ` Greg KH
  2019-09-23 23:54           ` Tim.Bird
@ 2019-09-26 12:52           ` David Sterba
  2019-09-27 13:52           ` Pavel Machek
  2019-10-03  9:08           ` Masahiro Yamada
  4 siblings, 0 replies; 23+ messages in thread
From: David Sterba @ 2019-09-26 12:52 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Linus Torvalds, Brendan Higgins, Shuah Khan, Mark Brown,
	Jarkko Sakkinen, Anders Roxell,
	open list:KERNEL SELFTEST FRAMEWORK, Linux Kernel Mailing List

On Sun, Sep 22, 2019 at 01:25:55PM +0200, Ingo Molnar wrote:
> 
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> > On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins
> > <brendanhiggins@google.com> wrote:
> > >
> > > Sorry about that. I am surprised that none of the other reviewers
> > > brought this up.
> > 
> > I think I'm "special".
> > 
> > There was some other similar change a few years ago, which I
> > absolutely hated because of how it broke autocomplete for me. Very few
> > other people seemed to react to it.
> 
> FWIW, I am obsessively sensitive to autocomplete and overall source code 
> file hieararchy and nomenclature details as well, so it's not just you.
> 
> Beyond the muscle memory aspect, nonsensical naming and inanely flat file 
> hierarchies annoy kernel developers and makes it harder for newbies to 
> understand the kernel source as well.
> 
> The less clutter, the more organization, the better - and there's very 
> few valid technical reasons to add any new files or directories to the 
> top level directory - we should probably *remove* quite a few.
> 
> For example 'firmware/' was recently moved to drivers/firmware/, and in a 
> similar fashion about a third of the remaining 22 directories should 
> probably be moved too:
> 
>   drwxr-xr-x    arch
>   drwxr-xr-x    block
>   drwxr-xr-x    certs           # move to build/certs/ dir
>   drwxr-xr-x    crypto          # move to kernel/crypto/ or security/crypto/

For code with lots of history and active development, moving is quite
counterproductive as it makes tracking a change tedious. Git can follow
the path changes, but that's exactly the step I'd like not to do. That's
similar to pure whitespace cleanup patches that are noise.

The decision for move should be IMO up to the maintainers of the code,
that apparently worked for firmware/ -> drivers/firmware that has been
mentioned.  That's fine.

The muscle memory argument sounds quite weak to me, each of us has some
habits, editor settings and coding style preferences, we will never
agree. That's fine too.

The reason I'd find valid for moving is to reduce confusion when working
with the files, not to promote a "formally correct classification" and
hierarchy of directories that will stand in the way in the daily work.

Though I'm not directly affected by most of the proposed changes, I feel
I should speak up before the file maneuvers reach code I care about.

>  - 'block' could in principle move to drivers/block/core/ but it's fine 
>    at the top level too I think.

Following that principle, we can move mm/ -> drivers/char/memory/ right? :)

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
  2019-09-22 11:25         ` Ingo Molnar
                             ` (2 preceding siblings ...)
  2019-09-26 12:52           ` David Sterba
@ 2019-09-27 13:52           ` Pavel Machek
  2019-10-03  9:08           ` Masahiro Yamada
  4 siblings, 0 replies; 23+ messages in thread
From: Pavel Machek @ 2019-09-27 13:52 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Linus Torvalds, Brendan Higgins, Shuah Khan, Mark Brown,
	Jarkko Sakkinen, Anders Roxell,
	open list:KERNEL SELFTEST FRAMEWORK, Linux Kernel Mailing List

Hi!

> > I think I'm "special".
> > 
> > There was some other similar change a few years ago, which I
> > absolutely hated because of how it broke autocomplete for me. Very few
> > other people seemed to react to it.
> 
> FWIW, I am obsessively sensitive to autocomplete and overall source code 
> file hieararchy and nomenclature details as well, so it's not just you.
> 
> Beyond the muscle memory aspect, nonsensical naming and inanely flat file 
> hierarchies annoy kernel developers and makes it harder for newbies to 
> understand the kernel source as well.
> 
> The less clutter, the more organization, the better - and there's very 
> few valid technical reasons to add any new files or directories to the 
> top level directory - we should probably *remove* quite a few.
> 
> For example 'firmware/' was recently moved to drivers/firmware/, and in a 
> similar fashion about a third of the remaining 22 directories should 
> probably be moved too:
> 
>   drwxr-xr-x    arch
>   drwxr-xr-x    block
>   drwxr-xr-x    certs           # move to build/certs/ dir
>   drwxr-xr-x    crypto          # move to kernel/crypto/ or security/crypto/
>   drwxr-xr-x    Documentation
>   drwxr-xr-x    drivers
>   drwxr-xr-x    fs
>   drwxr-xr-x    include
>   drwxr-xr-x    init
>   drwxr-xr-x    ipc             # move to kernel/ipc/
>   drwxr-xr-x    kernel
>   drwxr-xr-x    lib
>   drwxr-xr-x    LICENSES
>   drwxr-xr-x    mm
>   drwxr-xr-x    net
>   drwxr-xr-x    samples         # move to Documentation/samples/
>   drwxr-xr-x    scripts         # move to build/scripts/
>   drwxr-xr-x    security
>   drwxr-xr-x    sound           # move to drivers/sound/

Heh, I was always surprised that sound/ made it into top level... and no, I'd not
mind it being moved away.

> There's a few borderline ones:
> 
>  - 'block' could in principle move to drivers/block/core/ but it's fine 
>    at the top level too I think.
> 
>  - 'init' could in principle be moved to kernel/init/ - but it's not 
>    wrong at the top level either.

net would also make sense as drivers/net/core... That is what inspired sound/ afaict.

> I'm volunteering to do this (in a scripted, repeatable, reviewable, 
> tweakable and "easy to execute in a quiet moment" fashion), although
> I also expect you to balk at the churn. :-)

I'd like to see that happen...

Best regards,
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
  2019-09-22 11:25         ` Ingo Molnar
                             ` (3 preceding siblings ...)
  2019-09-27 13:52           ` Pavel Machek
@ 2019-10-03  9:08           ` Masahiro Yamada
  4 siblings, 0 replies; 23+ messages in thread
From: Masahiro Yamada @ 2019-10-03  9:08 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Linus Torvalds, Brendan Higgins, Shuah Khan, Mark Brown,
	Jarkko Sakkinen, Anders Roxell,
	open list:KERNEL SELFTEST FRAMEWORK, Linux Kernel Mailing List

On Sun, Sep 22, 2019 at 8:26 PM Ingo Molnar <mingo@kernel.org> wrote:
>
>
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> > On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins
> > <brendanhiggins@google.com> wrote:
> > >
> > > Sorry about that. I am surprised that none of the other reviewers
> > > brought this up.
> >
> > I think I'm "special".
> >
> > There was some other similar change a few years ago, which I
> > absolutely hated because of how it broke autocomplete for me. Very few
> > other people seemed to react to it.
>
> FWIW, I am obsessively sensitive to autocomplete and overall source code
> file hieararchy and nomenclature details as well, so it's not just you.
>
> Beyond the muscle memory aspect, nonsensical naming and inanely flat file
> hierarchies annoy kernel developers and makes it harder for newbies to
> understand the kernel source as well.
>
> The less clutter, the more organization, the better - and there's very
> few valid technical reasons to add any new files or directories to the
> top level directory - we should probably *remove* quite a few.
>
> For example 'firmware/' was recently moved to drivers/firmware/, and in a
> similar fashion about a third of the remaining 22 directories should
> probably be moved too:
>
>   drwxr-xr-x    arch
>   drwxr-xr-x    block
>   drwxr-xr-x    certs           # move to build/certs/ dir
>   drwxr-xr-x    crypto          # move to kernel/crypto/ or security/crypto/
>   drwxr-xr-x    Documentation
>   drwxr-xr-x    drivers
>   drwxr-xr-x    fs
>   drwxr-xr-x    include
>   drwxr-xr-x    init
>   drwxr-xr-x    ipc             # move to kernel/ipc/
>   drwxr-xr-x    kernel
>   drwxr-xr-x    lib
>   drwxr-xr-x    LICENSES
>   drwxr-xr-x    mm
>   drwxr-xr-x    net
>   drwxr-xr-x    samples         # move to Documentation/samples/
>   drwxr-xr-x    scripts         # move to build/scripts/
>   drwxr-xr-x    security
>   drwxr-xr-x    sound           # move to drivers/sound/
>   drwxr-xr-x    tools
>   drwxr-xr-x    usr             # move to build/usr/
>   drwxr-xr-x    virt            # move to the already existing drivers/virt/
>
>   -rw-r--r--    COPYING
>   -rw-r--r--    CREDITS
>   -rw-r--r--    Kbuild
>   -rw-r--r--    Kconfig
>   -rw-r--r--    MAINTAINERS
>   -rw-r--r--    Makefile
>   -rw-r--r--    README
>
> There's a few borderline ones:
>
>  - 'block' could in principle move to drivers/block/core/ but it's fine
>    at the top level too I think.
>
>  - 'init' could in principle be moved to kernel/init/ - but it's not
>    wrong at the top level either.
>
> The remaining top level hierarchy would look pretty sweet and short:
>
>   drwxr-xr-x    arch
>   drwxr-xr-x    block
>   drwxr-xr-x    build             # new

I am opposed to the "build".

The build tools will go too deep, like build/scripts/kconfig ?

I often use checkpatch.pl, get_maintainer.pl etc.

Do I have to type build/scripts/checkpatch.pl ?






>   drwxr-xr-x    Documentation
>   drwxr-xr-x    drivers
>   drwxr-xr-x    fs
>   drwxr-xr-x    include
>   drwxr-xr-x    init
>   drwxr-xr-x    kernel
>   drwxr-xr-x    lib
>   drwxr-xr-x    LICENSES
>   drwxr-xr-x    mm
>   drwxr-xr-x    net
>   drwxr-xr-x    security
>   drwxr-xr-x    tools
>
>   -rw-r--r--    COPYING
>   -rw-r--r--    CREDITS
>   -rw-r--r--    Kbuild
>   -rw-r--r--    Kconfig
>   -rw-r--r--    MAINTAINERS
>   -rw-r--r--    Makefile
>   -rw-r--r--    README
>
> I'm volunteering to do this (in a scripted, repeatable, reviewable,
> tweakable and "easy to execute in a quiet moment" fashion), although
> I also expect you to balk at the churn. :-)
>
> Thanks,
>
>         Ingo



-- 
Best Regards
Masahiro Yamada

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
  2019-09-23 22:40 Shuah Khan
@ 2019-09-26 20:10 ` pr-tracker-bot
  0 siblings, 0 replies; 23+ messages in thread
From: pr-tracker-bot @ 2019-09-26 20:10 UTC (permalink / raw)
  To: Shuah Khan
  Cc: Linus Torvalds, Mark Brown, Jarkko Sakkinen, Anders Roxell,
	Linux Kernel Mailing List, open list:KERNEL SELFTEST FRAMEWORK,
	Shuah Khan

The pull request you sent on Mon, 23 Sep 2019 16:40:15 -0600:

> git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest tags/linux-kselftest-5.4-rc1.1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/797a3242755da1b7c1ada6fb153cb2700ef30a80

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [GIT PULL] Kselftest update for Linux 5.4-rc1
@ 2019-09-23 22:40 Shuah Khan
  2019-09-26 20:10 ` pr-tracker-bot
  0 siblings, 1 reply; 23+ messages in thread
From: Shuah Khan @ 2019-09-23 22:40 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Mark Brown, Jarkko Sakkinen, Anders Roxell,
	Linux Kernel Mailing List, open list:KERNEL SELFTEST FRAMEWORK,
	Shuah Khan

[-- Attachment #1: Type: text/plain, Size: 2590 bytes --]

Hi Linus,

Please pull the following Kselftest update for Linux 5.4-rc1.

This Kselftest update for Linux 5.4-rc1 consists of several fixes to
existing tests.

diff is attached.

This pull has just the ksleftest patches I sent in my previous pull
request. I dropped the KUnit patches and rebased.

I will send another pull request for the KUnit work later on this
week.

Please note that there is conflict between

tools/testing/selftests/tpm2/Makefile

between commit:

   3fb2179b0f3553a ("selftests/tpm2: Add the missing TEST_FILES assignment")

from the tpmdd tree and commit:

   d04e26067d13f01 ("selftests: tpm2: install python files")

Please take the fix from kselftest tree which is the correct
version for this change.

d04e26067d13f01 ("selftests: tpm2: install python files")

Please let me know if you have any questions and/or concerns.

thanks,
-- Shuah

----------------------------------------------------------------

The following changes since commit d1abaeb3be7b5fa6d7a1fbbd2e14e3310005c4c1:

   Linux 5.3-rc5 (2019-08-18 14:31:08 -0700)

are available in the Git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest 
tags/linux-kselftest-5.4-rc1.1

for you to fetch changes up to 721cb3c8bc8890e824b7be53bf951960ff7811f9:

   selftests: tpm2: install python files (2019-09-23 08:33:16 -0600)

----------------------------------------------------------------
linux-kselftest-5.4-rc1.1

This Kselftest update for Linux 5.4-rc1 consists of fixes to existing
tests.

----------------------------------------------------------------
Anders Roxell (2):
       selftests: livepatch: add missing fragments to config
       selftests: tpm2: install python files

George G. Davis (2):
       selftests: watchdog: Add optional file argument
       selftests: watchdog: cleanup whitespace in usage options

Ilya Leoshkevich (1):
       selftests: use "$(MAKE)" instead of "make"

Masanari Iida (1):
       selftest/ftrace: Fix typo in trigger-snapshot.tc

Tycho Andersen (1):
       selftests/seccomp: fix build on older kernels

  tools/testing/selftests/Makefile                   | 22 ++++++------
  .../ftrace/test.d/trigger/trigger-snapshot.tc      |  2 +-
  tools/testing/selftests/livepatch/config           |  2 ++
  tools/testing/selftests/seccomp/seccomp_bpf.c      |  5 +++
  tools/testing/selftests/tpm2/Makefile              |  1 +
  tools/testing/selftests/watchdog/watchdog-test.c   | 41 
+++++++++++++++-------
  6 files changed, 48 insertions(+), 25 deletions(-)
----------------------------------------------------------------

[-- Attachment #2: linux-kselftest-5.4-rc1.1.diff --]
[-- Type: text/x-patch, Size: 8373 bytes --]

diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 25b43a8c2b15..c3feccb99ff5 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -126,9 +126,9 @@ endif
 # in the default INSTALL_HDR_PATH usr/include.
 khdr:
 ifeq (1,$(DEFAULT_INSTALL_HDR_PATH))
-	make --no-builtin-rules ARCH=$(ARCH) -C $(top_srcdir) headers_install
+	$(MAKE) --no-builtin-rules ARCH=$(ARCH) -C $(top_srcdir) headers_install
 else
-	make --no-builtin-rules INSTALL_HDR_PATH=$$BUILD/usr \
+	$(MAKE) --no-builtin-rules INSTALL_HDR_PATH=$$BUILD/usr \
 		ARCH=$(ARCH) -C $(top_srcdir) headers_install
 endif
 
@@ -136,35 +136,35 @@ all: khdr
 	@for TARGET in $(TARGETS); do		\
 		BUILD_TARGET=$$BUILD/$$TARGET;	\
 		mkdir $$BUILD_TARGET  -p;	\
-		make OUTPUT=$$BUILD_TARGET -C $$TARGET;\
+		$(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET;\
 	done;
 
 run_tests: all
 	@for TARGET in $(TARGETS); do \
 		BUILD_TARGET=$$BUILD/$$TARGET;	\
-		make OUTPUT=$$BUILD_TARGET -C $$TARGET run_tests;\
+		$(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET run_tests;\
 	done;
 
 hotplug:
 	@for TARGET in $(TARGETS_HOTPLUG); do \
 		BUILD_TARGET=$$BUILD/$$TARGET;	\
-		make OUTPUT=$$BUILD_TARGET -C $$TARGET;\
+		$(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET;\
 	done;
 
 run_hotplug: hotplug
 	@for TARGET in $(TARGETS_HOTPLUG); do \
 		BUILD_TARGET=$$BUILD/$$TARGET;	\
-		make OUTPUT=$$BUILD_TARGET -C $$TARGET run_full_test;\
+		$(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET run_full_test;\
 	done;
 
 clean_hotplug:
 	@for TARGET in $(TARGETS_HOTPLUG); do \
 		BUILD_TARGET=$$BUILD/$$TARGET;	\
-		make OUTPUT=$$BUILD_TARGET -C $$TARGET clean;\
+		$(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET clean;\
 	done;
 
 run_pstore_crash:
-	make -C pstore run_crash
+	$(MAKE) -C pstore run_crash
 
 # Use $BUILD as the default install root. $BUILD points to the
 # right output location for the following cases:
@@ -184,7 +184,7 @@ ifdef INSTALL_PATH
 	install -m 744 kselftest/prefix.pl $(INSTALL_PATH)/kselftest/
 	@for TARGET in $(TARGETS); do \
 		BUILD_TARGET=$$BUILD/$$TARGET;	\
-		make OUTPUT=$$BUILD_TARGET -C $$TARGET INSTALL_PATH=$(INSTALL_PATH)/$$TARGET install; \
+		$(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET INSTALL_PATH=$(INSTALL_PATH)/$$TARGET install; \
 	done;
 
 	@# Ask all targets to emit their test scripts
@@ -203,7 +203,7 @@ ifdef INSTALL_PATH
 		echo "[ -w /dev/kmsg ] && echo \"kselftest: Running tests in $$TARGET\" >> /dev/kmsg" >> $(ALL_SCRIPT); \
 		echo "cd $$TARGET" >> $(ALL_SCRIPT); \
 		echo -n "run_many" >> $(ALL_SCRIPT); \
-		make -s --no-print-directory OUTPUT=$$BUILD_TARGET -C $$TARGET emit_tests >> $(ALL_SCRIPT); \
+		$(MAKE) -s --no-print-directory OUTPUT=$$BUILD_TARGET -C $$TARGET emit_tests >> $(ALL_SCRIPT); \
 		echo "" >> $(ALL_SCRIPT);	    \
 		echo "cd \$$ROOT" >> $(ALL_SCRIPT); \
 	done;
@@ -216,7 +216,7 @@ endif
 clean:
 	@for TARGET in $(TARGETS); do \
 		BUILD_TARGET=$$BUILD/$$TARGET;	\
-		make OUTPUT=$$BUILD_TARGET -C $$TARGET clean;\
+		$(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET clean;\
 	done;
 
 .PHONY: khdr all run_tests hotplug run_hotplug clean_hotplug run_pstore_crash install clean
diff --git a/tools/testing/selftests/ftrace/test.d/trigger/trigger-snapshot.tc b/tools/testing/selftests/ftrace/test.d/trigger/trigger-snapshot.tc
index 7717c0a09686..ac738500d17f 100644
--- a/tools/testing/selftests/ftrace/test.d/trigger/trigger-snapshot.tc
+++ b/tools/testing/selftests/ftrace/test.d/trigger/trigger-snapshot.tc
@@ -28,7 +28,7 @@ if [ -z "$FEATURE" ]; then
     exit_unsupported
 fi
 
-echo "Test snapshot tigger"
+echo "Test snapshot trigger"
 echo 0 > snapshot
 echo 1 > events/sched/sched_process_fork/enable
 ( echo "forked")
diff --git a/tools/testing/selftests/livepatch/config b/tools/testing/selftests/livepatch/config
index 0dd7700464a8..ad23100cb27c 100644
--- a/tools/testing/selftests/livepatch/config
+++ b/tools/testing/selftests/livepatch/config
@@ -1 +1,3 @@
+CONFIG_LIVEPATCH=y
+CONFIG_DYNAMIC_DEBUG=y
 CONFIG_TEST_LIVEPATCH=m
diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c b/tools/testing/selftests/seccomp/seccomp_bpf.c
index 6ef7f16c4cf5..7f8b5c8982e3 100644
--- a/tools/testing/selftests/seccomp/seccomp_bpf.c
+++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
@@ -199,6 +199,11 @@ struct seccomp_notif_sizes {
 };
 #endif
 
+#ifndef PTRACE_EVENTMSG_SYSCALL_ENTRY
+#define PTRACE_EVENTMSG_SYSCALL_ENTRY	1
+#define PTRACE_EVENTMSG_SYSCALL_EXIT	2
+#endif
+
 #ifndef seccomp
 int seccomp(unsigned int op, unsigned int flags, void *args)
 {
diff --git a/tools/testing/selftests/tpm2/Makefile b/tools/testing/selftests/tpm2/Makefile
index 9dd848427a7b..1a5db1eb8ed5 100644
--- a/tools/testing/selftests/tpm2/Makefile
+++ b/tools/testing/selftests/tpm2/Makefile
@@ -2,3 +2,4 @@
 include ../lib.mk
 
 TEST_PROGS := test_smoke.sh test_space.sh
+TEST_PROGS_EXTENDED := tpm2.py tpm2_tests.py
diff --git a/tools/testing/selftests/watchdog/watchdog-test.c b/tools/testing/selftests/watchdog/watchdog-test.c
index c2333c78cf04..afff120c7be6 100644
--- a/tools/testing/selftests/watchdog/watchdog-test.c
+++ b/tools/testing/selftests/watchdog/watchdog-test.c
@@ -19,7 +19,7 @@
 
 int fd;
 const char v = 'V';
-static const char sopts[] = "bdehp:t:Tn:NL";
+static const char sopts[] = "bdehp:t:Tn:NLf:";
 static const struct option lopts[] = {
 	{"bootstatus",          no_argument, NULL, 'b'},
 	{"disable",             no_argument, NULL, 'd'},
@@ -31,6 +31,7 @@ static const struct option lopts[] = {
 	{"pretimeout",    required_argument, NULL, 'n'},
 	{"getpretimeout",       no_argument, NULL, 'N'},
 	{"gettimeleft",		no_argument, NULL, 'L'},
+	{"file",          required_argument, NULL, 'f'},
 	{NULL,                  no_argument, NULL, 0x0}
 };
 
@@ -69,16 +70,19 @@ static void term(int sig)
 static void usage(char *progname)
 {
 	printf("Usage: %s [options]\n", progname);
-	printf(" -b, --bootstatus    Get last boot status (Watchdog/POR)\n");
-	printf(" -d, --disable       Turn off the watchdog timer\n");
-	printf(" -e, --enable        Turn on the watchdog timer\n");
-	printf(" -h, --help          Print the help message\n");
-	printf(" -p, --pingrate=P    Set ping rate to P seconds (default %d)\n", DEFAULT_PING_RATE);
-	printf(" -t, --timeout=T     Set timeout to T seconds\n");
-	printf(" -T, --gettimeout    Get the timeout\n");
-	printf(" -n, --pretimeout=T  Set the pretimeout to T seconds\n");
-	printf(" -N, --getpretimeout Get the pretimeout\n");
-	printf(" -L, --gettimeleft   Get the time left until timer expires\n");
+	printf(" -f, --file\t\tOpen watchdog device file\n");
+	printf("\t\t\tDefault is /dev/watchdog\n");
+	printf(" -b, --bootstatus\tGet last boot status (Watchdog/POR)\n");
+	printf(" -d, --disable\t\tTurn off the watchdog timer\n");
+	printf(" -e, --enable\t\tTurn on the watchdog timer\n");
+	printf(" -h, --help\t\tPrint the help message\n");
+	printf(" -p, --pingrate=P\tSet ping rate to P seconds (default %d)\n",
+	       DEFAULT_PING_RATE);
+	printf(" -t, --timeout=T\tSet timeout to T seconds\n");
+	printf(" -T, --gettimeout\tGet the timeout\n");
+	printf(" -n, --pretimeout=T\tSet the pretimeout to T seconds\n");
+	printf(" -N, --getpretimeout\tGet the pretimeout\n");
+	printf(" -L, --gettimeleft\tGet the time left until timer expires\n");
 	printf("\n");
 	printf("Parameters are parsed left-to-right in real-time.\n");
 	printf("Example: %s -d -t 10 -p 5 -e\n", progname);
@@ -92,14 +96,20 @@ int main(int argc, char *argv[])
 	int ret;
 	int c;
 	int oneshot = 0;
+	char *file = "/dev/watchdog";
 
 	setbuf(stdout, NULL);
 
-	fd = open("/dev/watchdog", O_WRONLY);
+	while ((c = getopt_long(argc, argv, sopts, lopts, NULL)) != -1) {
+		if (c == 'f')
+			file = optarg;
+	}
+
+	fd = open(file, O_WRONLY);
 
 	if (fd == -1) {
 		if (errno == ENOENT)
-			printf("Watchdog device not enabled.\n");
+			printf("Watchdog device (%s) not found.\n", file);
 		else if (errno == EACCES)
 			printf("Run watchdog as root.\n");
 		else
@@ -108,6 +118,8 @@ int main(int argc, char *argv[])
 		exit(-1);
 	}
 
+	optind = 0;
+
 	while ((c = getopt_long(argc, argv, sopts, lopts, NULL)) != -1) {
 		switch (c) {
 		case 'b':
@@ -190,6 +202,9 @@ int main(int argc, char *argv[])
 			else
 				printf("WDIOC_GETTIMELEFT error '%s'\n", strerror(errno));
 			break;
+		case 'f':
+			/* Handled above */
+			break;
 
 		default:
 			usage(argv[0]);

^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2019-10-03  9:27 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <be8059f4-8e8f-cd18-0978-a9c861f6396b@linuxfoundation.org>
2019-09-20 16:17 ` [GIT PULL] Kselftest update for Linux 5.4-rc1 Linus Torvalds
2019-09-20 16:26   ` Randy Dunlap
     [not found]   ` <CAKRRn-edxk9Du70A27V=d3Na73fh=fVvGEVsQRGROrQm05YRrA@mail.gmail.com>
2019-09-20 16:35     ` Brendan Higgins
2019-09-20 16:51       ` Linus Torvalds
2019-09-20 18:03         ` Brendan Higgins
2019-09-20 18:14           ` Linus Torvalds
2019-09-20 18:16             ` Brendan Higgins
2019-09-20 18:06         ` Shuah Khan
2019-09-22 11:25         ` Ingo Molnar
2019-09-22 11:52           ` Greg KH
2019-09-23 14:44             ` Shuah Khan
2019-09-23 19:43               ` Ingo Molnar
2019-09-23 19:52                 ` Randy Dunlap
2019-09-23 20:29                   ` Shuah Khan
2019-09-23 20:53                     ` Ingo Molnar
2019-09-23 21:11                       ` Shuah Khan
2019-09-23 23:54           ` Tim.Bird
2019-09-24  8:07             ` Ingo Molnar
2019-09-26 12:52           ` David Sterba
2019-09-27 13:52           ` Pavel Machek
2019-10-03  9:08           ` Masahiro Yamada
2019-09-23 22:40 Shuah Khan
2019-09-26 20:10 ` pr-tracker-bot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).