> -Original Message-
> From: Thomas Gleixner
> On Tue, Apr 08 2025 at 17:34, Tim Bird wrote:
> >> -Original Message-
> > For what it's worth, I've always been a bit skeptical of the use of the
> > python git module
> > in spdxcheck.py. Its use makes it impossible to use spdxcheck
> -Original Message-
> From: Gon Solo
> It's a known problem:
> https://github.com/gitpython-developers/GitPython/issues/2003
> https://github.com/python/cpython/issues/118761#issuecomment-2661504264
>
For what it's worth, I've always been a bit skeptical of the use of the python
git mo
Add a count of files missing an SPDX header to the stats
output. This is useful detailed information for working
on SPDX header additions.
Signed-off-by: Tim Bird
---
scripts/spdxcheck.py | 3 +++
1 file changed, 3 insertions(+)
diff --git a/scripts/spdxcheck.py b/scripts/spdxcheck.py
index 18
> -Original Message-
> From: David Gow
>
> On Wed, Nov 11, 2020 at 1:02 AM Bird, Tim wrote:
> >
> > > -Original Message-
> > > From: David Gow
> > >
> > > On Mon, Nov 9, 2020 at 2:49 PM Arpitha Raghunandan <98.a...@gma
> -Original Message-
> From: David Gow
>
> On Mon, Nov 9, 2020 at 2:49 PM Arpitha Raghunandan <98.a...@gmail.com> wrote:
> >
> > On 07/11/20 3:36 pm, Marco Elver wrote:
> > > On Sat, 7 Nov 2020 at 05:58, David Gow wrote:
> > >> On Sat, Nov 7, 2020 at 3:22 AM Arpitha Raghunandan <98.a..
> -Original Message-
> From: Masami Hiramatsu
>
> Add tracing_on option description to the boot-time tracer.
>
> Signed-off-by: Masami Hiramatsu
> ---
> Documentation/trace/boottime-trace.rst |4
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/trace/boottim
ral,
> please refer
> +to the KUnit documentation in
> Documentation/dev-tools/kunit
> +
> + If unsure, say N
> +
> +
> +Test File and Module Names
> +==
> +
> +KUnit tests can often be compiled as a module. These modules should be named
> +after the test suite, followed by ``_test``. If this is likely to conflict
> with
> +non-KUnit tests, the suffic ``_kunit`` can also be used.
> +
> +The easiest way of achieving this is to name the file containing the test
> suite
> +``_test.c`` (or, as above, ``_kunit.c``). This file should be
> +placed next to the code under test.
> +
> +If the suite name contains some or all of the name of the test's parent
> +directory, it may make sense to modify the source filename to reduce
> redundancy.
> +For example, a ``foo_firmware`` suite could be in the ``foo/firmware_test.c``
> +file.
> +
> +
> --
> 2.28.0.526.ge36021eeef-goog
Looks good! I know this was a lot of hard work to get consensus here.
This will help a lot for test frameworks to have consistent and persistent,
fully-qualified names for testcases. Good job!
Reviewed-by: Tim Bird
-- Tim
> -Original Message-
> From: Brendan Higgins
> Sent: Friday, August 7, 2020 7:17 PM
>
> From: Heidi Fahim
>
> Add a --json flag, which when specified when kunit_tool is run,
> generates JSON formatted test results conforming to the KernelCI API
> test_group spec[1]. The user can the ne
> -Original Message-
> From: j...@joshtriplett.org
>
> On Fri, Jul 31, 2020 at 05:00:12PM +0200, Arnd Bergmann wrote:
> > The majority of the code in the kernel deals with hardware that was made
> > a long time ago, and we are regularly discussing which of those bits are
> > still needed.
> -Original Message-
> From: Laura Abbott
>
> On behalf of the Linux Foundation Technical Advisory Board (TAB), I'd
> like to announce the voting procedures for the 2020 TAB elections.
> The pool of eligible voters will consist of the following:
>
> 1) All attendees of the Linux Plumbers
> -Original Message-
> From: Steven Rostedt
>
> On Tue, 7 Jul 2020 09:49:21 +0300
> Mike Rapoport wrote:
>
> > > But that's all fine. The change is easy to do and is more descriptive
> > > even if I can't find terms that don't collide with my internal grammar
> > > checker. ;)
> >
> >
> -Original Message-
> From: Steven Rostedt
>
> On Tue, 7 Jul 2020 08:33:33 -0700
> Randy Dunlap wrote:
>
> > >> I was thinking good-list / bad-list.
> > >>
> > >> /me that has been doing a lot of git bisect lately...
> > >
> > > I think it depends on the context. I'd prefer a gramm
> -Original Message-
> From: Frank Rowand
>
> On 2020-06-21 17:49, Frank Rowand wrote:
> > On 2020-06-21 17:45, Frank Rowand wrote:
> >> Tim Bird started a thread [1] proposing that he document the selftest
> >> result
> >> format used by Linux kernel tests.
> >>
> >> [1]
> >> https:/
t;
> >> On Wed, Jun 17, 2020 at 02:30:45AM +, Bird, Tim wrote:
> >>> Agreed. You only need machine-parsable data if you expect the CI
> >>> system to do something more with the data than just present it.
> >>> What that would be, that would be common fo
> -Original Message-
> From: Kees Cook
>
> On Tue, Jun 16, 2020 at 09:16:01PM +0000, Bird, Tim wrote:
> > So far, most of the CI systems don't parse out diagnostic data, so it
> > doesn't
> > really matter what the format is. If it'
> -Original Message-
> From: Bird, Tim
>
> > Maybe in Documentation/dev-tools/ ?
> I'm leaning towards Documentation/dev-tools/test-results_format.rst
Ummm. Make that "test-results-format.rst"
(with a dash not an underline. I'm not insane, I swear...)
-- Tim
> -Original Message-
> From: Brendan Higgins
>
> On Wed, Jun 10, 2020 at 06:11:06PM +0000, Bird, Tim wrote:
> > Some months ago I started work on a document to formalize how
> > kselftest implements the TAP specification. However, I didn't finish
> >
> -Original Message-
> From: Brendan Higgins
>
> On Mon, Jun 15, 2020 at 10:34 AM Bird, Tim wrote:
> >
> > > -Original Message-
> > > From: David Gow
> > >
> > > On Thu, Jun 11, 2020 at 2:11 AM Bird, Tim wrote:
> [...]
> -Original Message-
> From: Brendan Higgins
>
> On Tue, Jun 16, 2020 at 9:42 AM Bird, Tim wrote:
>
> Apologies for taking so long to get to this. I have been busy with
> some stuff internally at Google.
>
> > > -Original Message-
> > &
> -Original Message-
> From: Paolo Bonzini
>
> On 15/06/20 21:07, Bird, Tim wrote:
> >> Note: making the plan line required differs from TAP13 and TAP14. I
> >> think it's the right choice, but we should be clear.
>
> As an aside, where i
> -Original Message-
> From: Paolo Bonzini
>
> On 10/06/20 19:43, Bird, Tim wrote:
> >>> (rc=$?; \
> >>> if [ $rc -eq $skip_rc ]; then \
> >>> - echo "not ok $test_num $TEST_HDR_M
Kees,
Thanks for the great feedback. See comments inline below.
> -Original Message-
> From: Kees Cook
>
> On Wed, Jun 10, 2020 at 06:11:06PM +0000, Bird, Tim wrote:
> > The kernel test result format consists of 5 major elements,
> > 4 of which are line-
> -Original Message-
> From: Kees Cook
> Sent: Sunday, June 14, 2020 12:18 PM
> To: David Gow
> Cc: Vitor Massaru Iha ; KUnit Development
> ; Shuah Khan
> ; open list:KERNEL SELFTEST FRAMEWORK
> ; Linux Kernel Mailing List
> ; Brendan Higgins ;
> linux-kernel-ment...@lists.linuxfound
> -Original Message-
> From: David Gow
>
> On Thu, Jun 11, 2020 at 2:11 AM Bird, Tim wrote:
> >
> > Some months ago I started work on a document to formalize how
> > kselftest implements the TAP specification. However, I didn't finish
> >
Some months ago I started work on a document to formalize how
kselftest implements the TAP specification. However, I didn't finish
that work. Maybe it's time to do so now.
kselftest has developed a few differences from the original
TAP specification, and some extensions that I believe are worth
> -Original Message-
> From: linux-kselftest-ow...@vger.kernel.org
> On Behalf Of Shuah Khan
>
> On 6/10/20 9:44 AM, Paolo Bonzini wrote:
> > According to the TAP specification, a skipped test must be marked as "ok"
> > and annotated with the SKIP directive, for example
> >
> > ok
> -Original Message-
> From: David Gow
>
> This is a proof-of-concept to support "skipping" tests.
>
> The kunit_mark_skipped() macro marks the current test as "skipped", with
> the provided reason. The kunit_skip() macro will mark the test as
> skipped, and abort the test.
>
> The TAP
On Monday, October 26, 2015 4:17 AM, Mark Rutland wrote:
>
> On Thu, Oct 22, 2015 at 02:12:17PM -0700, Tim Bird wrote:
> > Add a regulator to control the OTG chargepath switch. The OTG
> > switch gets its power from pm8941_5vs1, and that should be expressed
On Wednesday, September 24, 2014 11:21 AM, Kumar Gala [ga...@codeaurora.org]
wrote:
>
> On Sep 24, 2014, at 10:12 AM, Tim Bird wrote:
>
> > This DTS has support for the Sony Xperia Z1 phone (codenamed Honami).
> > This first version of the DTS supports just a serial console.
> >
> > changes from
On Saturday, August 23, 2014 6:35 AM, Bird, Tim wrote:
> Also, I've requested a 'test' wiki on kernel.org, where we can place
> notes, ideas, and lists of things to work on, or things in progress
> (like possible output format guidelines).
>
> I'll let ev
Signed-off-by:Tim Bird
Sent from my Sony Xperia™ smartphone
Felipe Balbi wrote
>On Thu, Apr 24, 2014 at 06:48:11PM +0300, Ivan T. Ivanov wrote:
>> From: Tim Bird
>>
>> Fix the value used for Parallel Transceiver Select (PTS) for the MSM USB
>> controller. This is a standard chipide
; Bird, Tim; tbird...@gmail.com
Cc: linux...@kvack.org; linux-kernel@vger.kernel.org; Bobniev, Roman
Subject: [PATCH] slub: proper kmemleak tracking if CONFIG_SLUB_DEBUG disabled
From: Roman Bobniev
Move more kmemleak calls into hook functions, and make it so
that all hooks (both inside and outside
On Wednesday, October 02, 2013 7:41 AM, Christoph Lameter [c...@linux.com]
wrote:
>
>On Fri, 27 Sep 2013, Frank Rowand wrote:
>
>> Move the kmemleak code for small block allocation out from
>> under CONFIG_SLUB_DEBUG.
>
>Well in that case it may be better to move the hooks as a whole out of
>the C
33 matches
Mail list logo
