On Mon, Aug 04, 2025 at 07:30:41PM -0400, Sasha Levin wrote:
> On Mon, Aug 04, 2025 at 03:53:50PM -0700, dan.j.willi...@intel.com wrote:
> >Steven Rostedt wrote:
> >> On Tue, 5 Aug 2025 00:03:29 +0200 (CEST)
> >> Jiri Kosina wrote:
> >>
> >> > Al made a very important point somewhere earlier in th
On Mon, Aug 04, 2025 at 03:53:50PM -0700, dan.j.willi...@intel.com wrote:
Steven Rostedt wrote:
On Tue, 5 Aug 2025 00:03:29 +0200 (CEST)
Jiri Kosina wrote:
> Al made a very important point somewhere earlier in this thread.
>
> The most important (from the code quality POV) thing is -- is there
Steven Rostedt wrote:
> On Tue, 5 Aug 2025 00:03:29 +0200 (CEST)
> Jiri Kosina wrote:
>
> > Al made a very important point somewhere earlier in this thread.
> >
> > The most important (from the code quality POV) thing is -- is there a
> > person that understands the patch enough to be able to a
On Mon, 4 Aug 2025, Steven Rostedt wrote:
> I know we can't change the DCO, but could we add something about our policy
> is that if you submit code, you certify that you understand said code, even
> if (especially) it was produced by AI?
Yeah, I think that's *precisely* what's needed.
Legal stu
On Tue, 5 Aug 2025 00:03:29 +0200 (CEST)
Jiri Kosina wrote:
> Al made a very important point somewhere earlier in this thread.
>
> The most important (from the code quality POV) thing is -- is there a
> person that understands the patch enough to be able to answer questions
> (coming from some
On Mon, 4 Aug 2025, Sasha Levin wrote:
> > The above guidance is quite vague. How me as a maintainer should know
> > that whatever AI tool has been used is meeting those two conditions
>
> In exactly the same way you know that a human contributor didn't copy
> code with an incompatible license.
>
On Tue, Jul 29, 2025 at 11:44 AM Mauro Carvalho Chehab
wrote:
>
> Python is listed as an optional dependency, but this is not
> true, as:
>
> 1) arm (multi_v7_defconfig and other defconfigs) and arm64 defconfig
>needs it due to DRM_MSM dependencies;
>
> 2) CONFIG_LTO_CLANG runs a python script
Hi Christoph,
On Mon, Jul 21, 2025 at 09:09:58AM +0200, Christoph Hellwig wrote:
> On Fri, Jul 18, 2025 at 08:22:26AM +0200, Thomas Weißschuh wrote:
> > > I had my own fair share of problems with kselftests,
> > > mostly because of the lack of structure and automated way to run them,
> >
> > How
On Mon, Aug 04, 2025 at 11:23:21AM +0200, Michal Hocko wrote:
On Mon 28-07-25 09:05:37, Sasha Levin wrote:
On Mon, Jul 28, 2025 at 12:47:55PM +0200, David Hildenbrand wrote:
> We cannot keep complaining about maintainer overload and, at the same
> time, encourage people to bombard us with even m
On Wed, 30 Jul 2025, Lorenzo Stoakes wrote:
> > This way we can extend MAINTAINERS to indicate which subsystems are
> > more open to research work (drivers/staging/ comes to mind) vs ones that
> > aren't.
> >
> > Some sort of a "traffic light" system:
> >
> > 1. Green: the subsystem is happy to r
On Mon 04-08-25 11:23:22, Michal Hocko wrote:
> On Mon 28-07-25 09:05:37, Sasha Levin wrote:
> > On Mon, Jul 28, 2025 at 12:47:55PM +0200, David Hildenbrand wrote:
> > > We cannot keep complaining about maintainer overload and, at the same
> > > time, encourage people to bombard us with even more o
On Mon 28-07-25 09:05:37, Sasha Levin wrote:
> On Mon, Jul 28, 2025 at 12:47:55PM +0200, David Hildenbrand wrote:
> > We cannot keep complaining about maintainer overload and, at the same
> > time, encourage people to bombard us with even more of that stuff.
> >
> > Clearly flagging stuff as AI-ge
On Sun, 3 Aug 2025 at 20:06, Soham Bagchi wrote:
>
> Updating the KCOV documentation to use a load-acquire
> operation for the first element of the shared memory
> buffer between kernel-space and user-space.
>
> The load-acquire pairs with the write memory barrier
> used in kcov_move_area()
>
> Si
On Sat, Aug 02, 2025 at 12:12:00PM +0200, Mauro Carvalho Chehab wrote:
> > Let's just decide whatever order b4 uses *is* the proper order, and save
> > ourselves endless hours of debating! :p
>
> I don't think it makes sense to have a "proper order" verified on
> checkpatch, as some tags may appea
Em Fri, 01 Aug 2025 10:55:55 +0300
Jani Nikula escreveu:
> On Thu, 31 Jul 2025, Krzysztof Kozlowski wrote:
> > On 31/07/2025 13:55, Geert Uytterhoeven wrote:
> >> B4 does not follow the proper order:
> >
> > There is no "proper order" in terms of absolute facts.
>
> Let's just decide what
On Wed, Jul 30, 2025 at 5:06 PM Kevin Hilman wrote:
>
> Sasha Levin writes:
>
> > Create a single source of truth for agent instructions in
> > Documentation/AI/main.md with symlinks for all major coding
> > agents:
> > - CLAUDE.md (Claude Code)
> > - .github/copilot-instructions.md (GitHub Copil
On 7/30/2025 7:57 PM, Konrad Dybcio wrote:
On 7/1/25 2:24 PM, Luo Jie wrote:
On 6/28/2025 12:21 AM, Konrad Dybcio wrote:
On 6/26/25 4:31 PM, Luo Jie wrote:
The PPE (Packet Process Engine) hardware block is available on Qualcomm
IPQ SoC that support PPE architecture, such as IPQ9574.
The
On Fri, Jul 25, 2025 at 07:21:12AM -0700, Jakub Kicinski wrote:
> On Fri, 25 Jul 2025 06:28:48 + Hangbin Liu wrote:
> > Add a selftest to verify bonding behavior when `lacp_active` is set to
> > `off`.
> >
> > The test checks the following:
> > - The passive LACP bond should not send LACPDUs
On Thu, 31 Jul 2025, Krzysztof Kozlowski wrote:
> On 31/07/2025 13:55, Geert Uytterhoeven wrote:
>> B4 does not follow the proper order:
>
> There is no "proper order" in terms of absolute facts.
Let's just decide whatever order b4 uses *is* the proper order, and save
ourselves endless hours of d
trampled by legacy apps or apps compiled with old kernel headers.
>
> In order to mitigate control-flow hijacting, kernel prepares a token and place
> it on shadow stack before signal delivery and places address of token in
> sigcontext structure. During sigreturn, kernel obtains address
On Tue, Jul 29, 2025 at 07:23:43PM -0700, Yuzhuo Jing wrote:
> In an effort to add RCU benchmarks to the perf tool and to improve
> the base-metal rcuscale tests, this patch series adds several auxiliary
> features useful for testing tools.
>
> This series introduces a few rcuscale options:
> *
On Tue, Jul 29, 2025 at 2:28 PM Oliver Upton wrote:
>
> On Fri, Jul 25, 2025 at 03:54:10PM -0700, Jiaqi Yan wrote:
> > On Sat, Jul 19, 2025 at 2:24 PM Jiaqi Yan wrote:
> > >
> > > On Sat, Jul 12, 2025 at 12:57 PM Oliver Upton
> > > wrote:
> > > >
> > > > On Fri, Jul 11, 2025 at 04:59:11PM -0700
Hello,
On Sat, 26 Jul 2025 18:44:29 -0300 Mark Brown wrote
---
> On Fri, Jul 25, 2025 at 11:37:13AM -0700, dan.j.willi...@intel.com wrote:
> > Jakub Kicinski wrote:
>
> > > So a tag would be ideal. But it's a hard nut to crack. Best I can come
> > > up with would be:
>
> >
On 2025-07-31, Christian Brauner wrote:
> On Fri, Jul 25, 2025 at 12:24:28PM +1000, Aleksa Sarai wrote:
> > On 2025-07-24, Christian Brauner wrote:
> > > On Wed, Jul 23, 2025 at 09:18:53AM +1000, Aleksa Sarai wrote:
> > > > /proc has historically had very opaque semantics about PID namespaces,
>
On 31/07/2025 13:55, Geert Uytterhoeven wrote:
> Hi Krzysztof,
>
> On Fri, 25 Jul 2025 at 10:42, Krzysztof Kozlowski wrote:
>> On 24/07/2025 09:20, Hendrik Hamerlinck wrote:
>>> Modified the checkpatch script to ensure that commit tags (e.g.,
>>> Signed-off-by, Reviewed-by, Acked-by, Tested-by, e
Hi Krzysztof,
On Fri, 25 Jul 2025 at 10:42, Krzysztof Kozlowski wrote:
> On 24/07/2025 09:20, Hendrik Hamerlinck wrote:
> > Modified the checkpatch script to ensure that commit tags (e.g.,
> > Signed-off-by, Reviewed-by, Acked-by, Tested-by, etc.) appear in the
> > correct order according to kern
On Fri, Jul 25, 2025 at 12:24:28PM +1000, Aleksa Sarai wrote:
> On 2025-07-24, Christian Brauner wrote:
> > On Wed, Jul 23, 2025 at 09:18:53AM +1000, Aleksa Sarai wrote:
> > > /proc has historically had very opaque semantics about PID namespaces,
> > > which is a little unfortunate for container r
Hi Yuzhuo,
kernel test robot noticed the following build errors:
[auto build test ERROR on rcu/rcu/dev]
[also build test ERROR on linus/master v6.16 next-20250731]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as docu
On Tue, 29 Jul 2025 18:43:04 +0200, Mauro Carvalho Chehab wrote:
> Python is listed as an optional dependency, but this is not
> true, as:
>
> 1) arm (multi_v7_defconfig and other defconfigs) and arm64 defconfig
>needs it due to DRM_MSM dependencies;
>
> 2) CONFIG_LTO_CLANG runs a python scri
Em Wed, 30 Jul 2025 13:46:47 -0400
Sasha Levin escreveu:
> >> Some sort of a "traffic light" system:
> >>
> >> 1. Green: the subsystem is happy to receive patches from any source.
> >>
> >> 2. Yellow: "If you're unfamiliar with the subsystem and using any
> >> tooling to generate your patch
On Wed, Jul 30, 2025 at 03:06:26PM -0700, Kevin Hilman wrote:
Sasha Levin writes:
Create a single source of truth for agent instructions in
Documentation/AI/main.md with symlinks for all major coding
agents:
- CLAUDE.md (Claude Code)
- .github/copilot-instructions.md (GitHub Copilot)
- .cursor
Sasha Levin writes:
> Create a single source of truth for agent instructions in
> Documentation/AI/main.md with symlinks for all major coding
> agents:
> - CLAUDE.md (Claude Code)
> - .github/copilot-instructions.md (GitHub Copilot)
> - .cursorrules (Cursor)
> - .codeium/instructions.md (Codeium)
On Wed, Jul 30, 2025 at 03:10:33PM -0400, Theodore Ts'o wrote:
> On Wed, Jul 30, 2025 at 06:59:09PM +0100, Al Viro wrote:
> >
> > And I absolutely will refuse to take patches from somebody who would
> > consistently fail to explain why the patch is correct and needed. Sasha,
> > this is the eleph
On Wed, 30 Jul 2025 15:10:33 -0400
"Theodore Ts'o" wrote:
> Any tool can be a force multipler, either for good or for ill.
>
> For example, I suspect we have a much greater set of problems from
> $TOOL's other than Large Language Models. For example people who use
> "git grep strcpy" and send p
On Wed, 30 Jul 2025 13:46:47 -0400
Sasha Levin wrote:
> >My point here is that AI can now add questions that maintainers can't
> >answer. Is it really legal? Can the maintainer trust it? Yes, these too can
> >fall under the "technical reasons" but having a clear policy that states
> >that a maint
On Wed, Jul 30, 2025 at 07:04:13PM +0100, Lorenzo Stoakes wrote:
> On Wed, Jul 30, 2025 at 01:32:20PM -0400, Steven Rostedt wrote:
> > If the maintainer starts getting too many submissions, then they can update
> > the MAINTAINERS file to say "stop all AI patches to me!". Just like we have
> > an
On Wed, Jul 30, 2025 at 06:59:09PM +0100, Al Viro wrote:
>
> And I absolutely will refuse to take patches from somebody who would
> consistently fail to explain why the patch is correct and needed. Sasha,
> this is the elephant in the room: we *ALREADY* get "contributions" that
> very clearly ste
On Wed, Jul 30, 2025 at 07:24:13PM +0100, Lorenzo Stoakes wrote:
On Wed, Jul 30, 2025 at 02:10:26PM -0400, Sasha Levin wrote:
On Wed, Jul 30, 2025 at 06:59:09PM +0100, Al Viro wrote:
> On Wed, Jul 30, 2025 at 01:46:47PM -0400, Sasha Levin wrote:
>
> > Similarily the argument around not trusting
On Wed, Jul 30, 2025 at 07:18:44PM +0100, Matthew Wilcox wrote:
On Wed, Jul 30, 2025 at 12:25:41PM -0400, Sasha Levin wrote:
Critical Requirements:
* License: ALL code MUST be GPL-2.0 only (see COPYING)
As I understand it, code generated by an LLM is free from copyright.
https://en.wikipedia.
On Wed, Jul 30, 2025 at 06:35:28PM +0100, Al Viro wrote:
On Wed, Jul 30, 2025 at 12:25:41PM -0400, Sasha Levin wrote:
Critical Requirements:
* License: ALL code MUST be GPL-2.0 only (see COPYING)
* Signed-off-by: Agents MUST NOT add Signed-off-by tags
(Only humans can legally certify code su
On Wed, Jul 30, 2025 at 02:10:26PM -0400, Sasha Levin wrote:
> On Wed, Jul 30, 2025 at 06:59:09PM +0100, Al Viro wrote:
> > On Wed, Jul 30, 2025 at 01:46:47PM -0400, Sasha Levin wrote:
> >
> > > Similarily the argument around not trusting the code is equivalent to
> > > not trusting the person who
On Wed, Jul 30, 2025 at 12:25:41PM -0400, Sasha Levin wrote:
> Critical Requirements:
>
> * License: ALL code MUST be GPL-2.0 only (see COPYING)
As I understand it, code generated by an LLM is free from copyright.
https://en.wikipedia.org/wiki/Monkey_selfie_copyright_dispute
On Wed, Jul 30, 2025 at 02:03:38PM -0400, Sasha Levin wrote:
> On Wed, Jul 30, 2025 at 01:32:20PM -0400, Steven Rostedt wrote:
> > On Wed, 30 Jul 2025 18:23:14 +0100
> > Lorenzo Stoakes wrote:
> > > You might suggest presuming a policy for maintainers is inappropriate, but
> > > you are doing so w
On Wed, Jul 30, 2025 at 06:59:09PM +0100, Al Viro wrote:
On Wed, Jul 30, 2025 at 01:46:47PM -0400, Sasha Levin wrote:
Similarily the argument around not trusting the code is equivalent to
not trusting the person who sent the code in. AI doesn't send patches on
it's own - humans do. This is basi
On Wed, Jul 30, 2025 at 01:32:20PM -0400, Steven Rostedt wrote:
On Wed, 30 Jul 2025 18:23:14 +0100
Lorenzo Stoakes wrote:
You might suggest presuming a policy for maintainers is inappropriate, but
you are doing so wrt the LF policy on the assumption everybody is aware and
agrees with it.
No,
On Wed, Jul 30, 2025 at 01:32:20PM -0400, Steven Rostedt wrote:
>
> >
> > Assuming every maintainer accepts AI patches unless explicitly opted out is
> > very clearly not something that will be acceptable to people.
>
> You can opt out when you receive your first AI patch ;-)
Yeah, there's just no
On Wed, Jul 30, 2025 at 01:46:47PM -0400, Sasha Levin wrote:
> Similarily the argument around not trusting the code is equivalent to
> not trusting the person who sent the code in. AI doesn't send patches on
> it's own - humans do. This is basically saying "I didn't even look at
> your patch becau
On Wed, Jul 30, 2025 at 04:40:39PM +, Dr. David Alan Gilbert wrote:
> b) There's a whole spectrum of:
> i) AI wrote the whole patch based on a vague requirement
> ii) AI is in the editor and tab completes stuff
> iii) AI suggests fixes/changes
> which do you care about?
Th
On Wed, Jul 30, 2025 at 01:05:31PM -0400, Steven Rostedt wrote:
On Wed, 30 Jul 2025 12:36:25 -0400
Sasha Levin wrote:
>
>That sounds pretty much exactly as what I was stating in our meeting. That
>is, it is OK to submit a patch written with AI but you must disclose it. It
>is also the right of
* Steven Rostedt (rost...@goodmis.org) wrote:
> On Wed, 30 Jul 2025 16:40:39 +
> "Dr. David Alan Gilbert" wrote:
>
> > * Steven Rostedt (rost...@goodmis.org) wrote:
> > > On Wed, 30 Jul 2025 16:34:28 +0100
> > > Lorenzo Stoakes wrote:
> > >
> > > > > Which looked like someone else (now Cc
On Wed, Jul 30, 2025 at 05:59:25PM +0100, Lorenzo Stoakes wrote:
> On Wed, Jul 30, 2025 at 12:36:25PM -0400, Sasha Levin wrote:
> > Some sort of a "traffic light" system:
> >
> > 1. Green: the subsystem is happy to receive patches from any source.
> >
> > 2. Yellow: "If you're unfamiliar with the
On Wed, Jul 30, 2025 at 12:25:41PM -0400, Sasha Levin wrote:
> Critical Requirements:
>
> * License: ALL code MUST be GPL-2.0 only (see COPYING)
> * Signed-off-by: Agents MUST NOT add Signed-off-by tags
> (Only humans can legally certify code submission rights)
> * Attribution: Agents MUST add
On Wed, Jul 30, 2025 at 05:59:25PM +0100, Lorenzo Stoakes wrote:
> On Wed, Jul 30, 2025 at 12:36:25PM -0400, Sasha Levin wrote:
> > Some sort of a "traffic light" system:
> > 1. Green: the subsystem is happy to receive patches from any source.
> > 2. Yellow: "If you're unfamiliar with the subs
On Wed, Jul 30, 2025 at 01:20:54PM -0400, Steven Rostedt wrote:
> On Wed, 30 Jul 2025 18:10:51 +0100
> Lorenzo Stoakes wrote:
>
>
> > > > I guess a statement in submitting-patches.rst would suffice, or should
> > > > it
> > > > be a separate standalone document?
> > >
> > > If it's separate I thi
On Wed, 30 Jul 2025 18:23:14 +0100
Lorenzo Stoakes wrote:
> > I don't think we should (or can) set a policy here for other
> > maintainers. Right now we allow tool-assisted contributions - flipping
> > this would mean we need to get an ack from at least a majority of the
> > MAINTAINERS folks.
On Wed, 30 Jul 2025 13:12:54 -0400
Sasha Levin wrote:
> >>
> >> Some sort of a "traffic light" system:
> >>
> >> 1. Green: the subsystem is happy to receive patches from any source.
> >>
> >> 2. Yellow: "If you're unfamiliar with the subsystem and using any
> >> tooling to generate your patche
On Wed, Jul 30, 2025 at 01:12:54PM -0400, Sasha Levin wrote:
> On Wed, Jul 30, 2025 at 05:59:25PM +0100, Lorenzo Stoakes wrote:
> > On Wed, Jul 30, 2025 at 12:36:25PM -0400, Sasha Levin wrote:
> > > On Wed, Jul 30, 2025 at 12:18:29PM -0400, Steven Rostedt wrote:
> > > > On Wed, 30 Jul 2025 16:34:28
On Wed, 30 Jul 2025 18:10:51 +0100
Lorenzo Stoakes wrote:
> > > I guess a statement in submitting-patches.rst would suffice, or should it
> > > be a separate standalone document?
> >
> > If it's separate I think it needs to have a link from submitting-patches.rst
> > to get people to read it.
On Wed, Jul 30, 2025 at 05:59:25PM +0100, Lorenzo Stoakes wrote:
On Wed, Jul 30, 2025 at 12:36:25PM -0400, Sasha Levin wrote:
On Wed, Jul 30, 2025 at 12:18:29PM -0400, Steven Rostedt wrote:
> On Wed, 30 Jul 2025 16:34:28 +0100
> Lorenzo Stoakes wrote:
>
> > > Which looked like someone else (now
On Wed, 30 Jul 2025 16:40:39 +
"Dr. David Alan Gilbert" wrote:
> * Steven Rostedt (rost...@goodmis.org) wrote:
> > On Wed, 30 Jul 2025 16:34:28 +0100
> > Lorenzo Stoakes wrote:
> >
> > > > Which looked like someone else (now Cc'd on this thread) took it
> > > > public,
>
> (I didn't k
On Wed, Jul 30, 2025 at 04:40:39PM +, Dr. David Alan Gilbert wrote:
> * Steven Rostedt (rost...@goodmis.org) wrote:
> > On Wed, 30 Jul 2025 16:34:28 +0100
> > Lorenzo Stoakes wrote:
> >
> > > > Which looked like someone else (now Cc'd on this thread) took it public,
>
> (I didn't know of the t
On Wed, 30 Jul 2025 12:36:25 -0400
Sasha Levin wrote:
> >
> >That sounds pretty much exactly as what I was stating in our meeting. That
> >is, it is OK to submit a patch written with AI but you must disclose it. It
> >is also the right of the Maintainer to refuse to take any patch that was
> >wri
On Wed, Jul 30, 2025 at 12:36:25PM -0400, Sasha Levin wrote:
> On Wed, Jul 30, 2025 at 12:18:29PM -0400, Steven Rostedt wrote:
> > On Wed, 30 Jul 2025 16:34:28 +0100
> > Lorenzo Stoakes wrote:
> >
> > > > Which looked like someone else (now Cc'd on this thread) took it public,
> > > > and I wanted
On Wed, Jul 30, 2025 at 12:18:29PM -0400, Steven Rostedt wrote:
> On Wed, 30 Jul 2025 16:34:28 +0100
> Lorenzo Stoakes wrote:
>
> > > Which looked like someone else (now Cc'd on this thread) took it public,
> > > and I wanted to see where that ended. I didn't want to start another
> > > discussion
* Steven Rostedt (rost...@goodmis.org) wrote:
> On Wed, 30 Jul 2025 16:34:28 +0100
> Lorenzo Stoakes wrote:
>
> > > Which looked like someone else (now Cc'd on this thread) took it public,
(I didn't know of the tab discussion)
> > > and I wanted to see where that ended. I didn't want to start a
On Wed, Jul 30, 2025 at 12:18:29PM -0400, Steven Rostedt wrote:
On Wed, 30 Jul 2025 16:34:28 +0100
Lorenzo Stoakes wrote:
> Which looked like someone else (now Cc'd on this thread) took it public,
> and I wanted to see where that ended. I didn't want to start another
> discussion when there's
Em Wed, 30 Jul 2025 12:18:29 -0400
Steven Rostedt escreveu:
> On Wed, 30 Jul 2025 16:34:28 +0100
> Lorenzo Stoakes wrote:
>
> > > Which looked like someone else (now Cc'd on this thread) took it public,
> > > and I wanted to see where that ended. I didn't want to start another
> > > discussion
On Sun, Jul 27, 2025 at 11:18:14PM -0700, Kees Cook wrote:
I think the above list is perfect contents for the README. Yes, please
make that an entry point, or point to some other .rst entry point that
will have a list of roles like that, with some common starting points.
And yes, a line for agent
On Wed, 30 Jul 2025 16:34:28 +0100
Lorenzo Stoakes wrote:
> > Which looked like someone else (now Cc'd on this thread) took it public,
> > and I wanted to see where that ended. I didn't want to start another
> > discussion when there's already two in progress.
>
> OK, but having a document lik
On Wed, Jul 30, 2025 at 11:27:53AM -0400, Steven Rostedt wrote:
> On Mon, 28 Jul 2025 11:52:47 +0100
> Lorenzo Stoakes wrote:
>
> > On Mon, Jul 28, 2025 at 12:35:02PM +0200, Greg KH wrote:
> > > > So to me:
> > > >
> > > > - We should establish an official kernel AI policy document.
> > >
> > > St
On Mon, 28 Jul 2025 11:52:47 +0100
Lorenzo Stoakes wrote:
> On Mon, Jul 28, 2025 at 12:35:02PM +0200, Greg KH wrote:
> > > So to me:
> > >
> > > - We should establish an official kernel AI policy document.
> >
> > Steven Rostedt is working on this right now, hopefully he has something
> > "soon
On Wed, 30 Jul 2025 11:31:35 +0200
Krzysztof Kozlowski wrote:
> I pop up there a lot, but there is no confusion. I am (and maybe we are
> all?) well aware that checkpatch hard limit is 100 as explained also here:
> https://lore.kernel.org/all/df2e466a-cdaa-4263-ae16-7bf56c0ed...@kernel.org/
>
>
On Wed, 30 Jul 2025 11:31:35 +0200 Krzysztof Kozlowski wrote:
> I pop up there a lot, but there is no confusion. I am (and maybe we are
> all?) well aware that checkpatch hard limit is 100 as explained also here:
> https://lore.kernel.org/all/df2e466a-cdaa-4263-ae16-7bf56c0ed...@kernel.org/
>
> Bu
On 7/1/25 2:24 PM, Luo Jie wrote:
>
>
> On 6/28/2025 12:21 AM, Konrad Dybcio wrote:
>> On 6/26/25 4:31 PM, Luo Jie wrote:
>>> The PPE (Packet Process Engine) hardware block is available on Qualcomm
>>> IPQ SoC that support PPE architecture, such as IPQ9574.
>>>
>>> The PPE in IPQ9574 includes six
On 28/07/2025 08:03, Sasha Levin wrote:
> On Sun, Jul 27, 2025 at 10:21:40PM -0700, Kees Cook wrote:
>> On Mon, Jul 28, 2025 at 01:10:25AM -0400, Sasha Levin wrote:
>>> On Sun, Jul 27, 2025 at 07:40:36PM -0700, Kees Cook wrote:
On Sun, Jul 27, 2025 at 03:58:01PM -0400, Sasha Levin wrote:
>
On Fri, Jul 25, 2025 at 03:54:10PM -0700, Jiaqi Yan wrote:
> On Sat, Jul 19, 2025 at 2:24 PM Jiaqi Yan wrote:
> >
> > On Sat, Jul 12, 2025 at 12:57 PM Oliver Upton
> > wrote:
> > >
> > > On Fri, Jul 11, 2025 at 04:59:11PM -0700, Jiaqi Yan wrote:
> > > > > - Add some detail about FEAT_RAS where
On Tue, 29 Jul 2025, Mauro Carvalho Chehab wrote:
> I don't think we should do much effort to support Python 2, but it comes
> almost for free: only shebang needs to be different, and, if the comments
> inside the doc contains non-utf8 chars, an encoding line.
As said in the other thread, changin
Em Tue, 29 Jul 2025 13:45:26 +0300
Jani Nikula escreveu:
> On Mon, 28 Jul 2025, Mauro Carvalho Chehab wrote:
> > Considering the above, for me it seems that the bus already departed:
> > there are several cases where Python is required during build time.
>
> FWIW, if it was up to me, I'd make
Em Tue, 29 Jul 2025 19:35:57 +0900
Akira Yokosawa escreveu:
> [+CC Laurent and Jani]
>
> Hi,
>
> On Mon, 28 Jul 2025 16:54:29 +0200, Mauro Carvalho Chehab wrote:
> > Python is listed as an optional dependency, but this is not
> > true, as:
> >
> > 1) CONFIG_LTO_CLANG runs a python script at sc
On Mon, 28 Jul 2025, Mauro Carvalho Chehab wrote:
> Considering the above, for me it seems that the bus already departed:
> there are several cases where Python is required during build time.
FWIW, if it was up to me, I'd make Python 3+ a non-optional build
dependency. I'd also forget about any P
[+CC Laurent and Jani]
Hi,
On Mon, 28 Jul 2025 16:54:29 +0200, Mauro Carvalho Chehab wrote:
> Python is listed as an optional dependency, but this is not
> true, as:
>
> 1) CONFIG_LTO_CLANG runs a python script at scripts/Makefile.vmlinux_o;
>
> 2) kernel-doc is called during compilation when s
Also, the same way a kernel
> maintainer needs to know how to produce a good code, someone using
> AI also must learn how to properly use the tool.
>
> After all, at least at the current stage, AI is not intelligent.
Heh, after re-reading my post, I realized that I could have been too
Em Mon, 28 Jul 2025 13:46:53 -0400
Steven Rostedt escreveu:
> On Fri, 25 Jul 2025 13:34:32 -0700
> wrote:
>
> > > This touches on explainability of AI. Perhaps the metadata would be
> > > interesting for XAI research... not sure that's enough to be lugging
> > > those tags in git history.
>
On Mon, 28 Jul 2025 at 20:43, Soham Bagchi wrote:
>
> Updating the KCOV documentation to use a load-acquire
> operation for the first element of the shared memory
> buffer between kernel-space and user-space.
>
> The load-acquire pairs with the write memory barrier
> used in kcov_move_area()
>
> S
On Mon, 28 Jul 2025 at 20:43, Soham Bagchi wrote:
>
> KCOV Remote uses two separate memory buffers, one private to the kernel
> space (kcov_remote_areas) and the second one shared between user and
> kernel space (kcov->area). After every pair of kcov_remote_start() and
> kcov_remote_stop(), the co
Steven Rostedt wrote:
> On Fri, 25 Jul 2025 13:34:32 -0700
> wrote:
>
> > > This touches on explainability of AI. Perhaps the metadata would be
> > > interesting for XAI research... not sure that's enough to be lugging
> > > those tags in git history.
> >
> > Agree. The "who to blame" is "Auth
On Fri, 25 Jul 2025 13:34:32 -0700
wrote:
> > This touches on explainability of AI. Perhaps the metadata would be
> > interesting for XAI research... not sure that's enough to be lugging
> > those tags in git history.
>
> Agree. The "who to blame" is "Author:". They signed DCO they are
> respo
Em Fri, 25 Jul 2025 13:53:57 -0700
Kees Cook escreveu:
> On Fri, Jul 25, 2025 at 01:53:58PM -0400, Sasha Levin wrote:
> > Add rules based on our existing documentation.
>
> I'd still like this not in Documentation/, but I obviously defer to Jon.
I think it should be at Documentation, under pr
Em Fri, 25 Jul 2025 13:53:56 -0400
Sasha Levin escreveu:
> This patch series adds unified configuration and documentation for AI
> coding assistants working with the Linux kernel codebase. As AI tools
> become increasingly common in software development, it's important to
> establish clear guidel
Em Sat, 26 Jul 2025 22:24:08 -0400
Sasha Levin escreveu:
> On Fri, Jul 25, 2025 at 06:15:33PM -0400, Sasha Levin wrote:
> >On Fri, Jul 25, 2025 at 12:27:50PM -0600, Jonathan Corbet wrote:
> >>Sasha Levin writes:
> >>
> >>>Create a single source of truth for AI instructions in
> >>>Documentat
On Mon, Jul 28, 2025 at 11:40 AM Kees Cook wrote:
>
> On Sun, Jul 27, 2025 at 03:45:42PM +, Dr. David Alan Gilbert wrote:
> > When doing qemu dev, I frequently run it in a tmux, and start it with
> > '-nographic' which gets you a single stream with both serial and monitor in
> > it;
> > alter
On July 28, 2025 8:57:21 AM PDT, dan.j.willi...@intel.com wrote:
>Kees Cook wrote:
>> Having had to do "find all commits from [set of authors]" research for
>> security audits, I would be very unhappy if I had to do this again in
>> the future for a specific Agent (used any author), and had to l
Kees Cook wrote:
> On Fri, Jul 25, 2025 at 03:00:46PM -0400, Steven Rostedt wrote:
> > Also, I would argue that it would be useful in the change log as if there's
> > a bug in the generated code, you know who or *what* to blame. Especially if
> > there is a pattern to be found.
>
> Yeah, this is w
Em Mon, 28 Jul 2025 12:28:45 +0300
Jani Nikula escreveu:
> On Thu, 24 Jul 2025, Mauro Carvalho Chehab wrote:
> > Em Thu, 24 Jul 2025 08:42:59 -0600
> > Jonathan Corbet escreveu:
> >
> >> Mauro Carvalho Chehab writes:
> >>
> >> > Maybe I can place instead CONFIG_DRM_I915_WERROR.
> >>
> >> I'v
On Mon, Jul 28, 2025 at 09:23:19AM -0400, Sasha Levin wrote:
> On Mon, Jul 28, 2025 at 02:13:01PM +0100, Lorenzo Stoakes wrote:
> > On Mon, Jul 28, 2025 at 08:45:19AM -0400, Sasha Levin wrote:
> > > > So at all times I think ensuring the human element is aware that they
> > > > need
> > > > to do
On Mon, Jul 28, 2025 at 02:13:01PM +0100, Lorenzo Stoakes wrote:
On Mon, Jul 28, 2025 at 08:45:19AM -0400, Sasha Levin wrote:
> So at all times I think ensuring the human element is aware that they need
> to do some kind of checking/filtering is key.
>
> But that can be handled by a carefully wo
On Mon, Jul 28, 2025 at 08:45:19AM -0400, Sasha Levin wrote:
> On Mon, Jul 28, 2025 at 11:52:47AM +0100, Lorenzo Stoakes wrote:
> > One thing to note is that I struggled to get an LLM to read MAINTAINERS
> > properly recently (it assured me, with absolute confidence, that the SLAB
> > ALLOCATOR sec
On Mon, Jul 28, 2025 at 12:47:55PM +0200, David Hildenbrand wrote:
We cannot keep complaining about maintainer overload and, at the same
time, encourage people to bombard us with even more of that stuff.
Clearly flagging stuff as AI-generated can maybe help. But really,
what we need is a prope
On Mon, Jul 28, 2025 at 11:52:47AM +0100, Lorenzo Stoakes wrote:
One thing to note is that I struggled to get an LLM to read MAINTAINERS
properly recently (it assured me, with absolute confidence, that the SLAB
ALLOCATOR section was in fact 'SLAB ALLOCATORS' + provided me with
completely incorrec
On Sun, Jul 27, 2025 at 11:18:14PM -0700, Kees Cook wrote:
On Mon, Jul 28, 2025 at 01:59:42AM -0400, Sasha Levin wrote:
Thing is, agents won't read the README on their own: they need to be
prompted to do it.
Claude does:
> /init
● I'll analyze the codebase and create a CLAUDE.md file to help
1 - 100 of 4043 matches
Mail list logo
