On Tue, Dec 19, 2023 at 08:29:50PM +0100, Thomas Weißschuh wrote:
> Hi Luis and Julia,
>
> (Julia, there is a question and context for you inline, marked with your name)
>
> On 2023-12-18 13:21:49-0800, Luis Chamberlain wrote:
> > So we can split this up concentually in two:
> >
> > * constific
On Sun, Dec 17, 2023 at 11:10:15PM +0100, Thomas Weißschuh wrote:
> On 2023-12-17 13:02:01+0100, Joel Granados wrote:
> > Catching up with mail
> >
> > On Tue, Dec 12, 2023 at 11:51:30PM -0800, Luis Chamberlain wrote:
> > > On Tue, Dec 12, 2023 at 10:09:30AM +0100, Joel Granados wrote:
> > > >
On Mon, Dec 18, 2023 at 01:21:49PM -0800, Luis Chamberlain wrote:
> So we can split this up concentually in two:
>
> * constificaiton of the table handlers
> * constification of the table struct itself
>
> On Sun, Dec 17, 2023 at 11:10:15PM +0100, Thomas Weißschuh wrote:
> > The handlers can al
On Wed, Dec 20, 2023 at 08:39:20AM +0100, Julia Lawall wrote:
>
>
> On Tue, 19 Dec 2023, Luis Chamberlain wrote:
>
> > On Tue, Dec 19, 2023 at 10:21:25PM +0100, Julia Lawall wrote:
> > > > As I noted, I think this is a generically neat endeavor and so I think
> > > > it would be nice to shorthan
On Tue, 19 Dec 2023, Luis Chamberlain wrote:
> On Tue, Dec 19, 2023 at 10:21:25PM +0100, Julia Lawall wrote:
> > > As I noted, I think this is a generically neat endeavor and so I think
> > > it would be nice to shorthand *any* member of the struct. ctl->any.
> > > Julia, is that possible?
> >
On Tue, Dec 19, 2023 at 10:21:25PM +0100, Julia Lawall wrote:
> > As I noted, I think this is a generically neat endeavor and so I think
> > it would be nice to shorthand *any* member of the struct. ctl->any.
> > Julia, is that possible?
>
> What do you mean by *any* member?
I meant when any code
I came up with the following:
@@
type t;
const t *x;
identifier y,z;
expression a;
assignment operator aop;
@@
(
(<+...(<+...x->y...+>)[...]...+>) aop a
|
(<+...(<+...x->y...+>)->z...+>) aop a
|
* (<+...x->y...+>) aop a
)
@fn disable optional_qualifier@
identifier f,x;
type t;
parameter list
> As I noted, I think this is a generically neat endeavor and so I think
> it would be nice to shorthand *any* member of the struct. ctl->any.
> Julia, is that possible?
What do you mean by *any* member? If any is an identifier typed
metavariable then that would get any immediate member. But may
On Tue, Dec 19, 2023 at 08:29:50PM +0100, Thomas Weißschuh wrote:
>
> I used the following coccinelle script to find more handlers that I
> missed before:
>
> virtual patch
> virtual context
> virtual report
>
> @@
> identifier func;
> identifier ctl;
> identifier write;
> identifier buffer;
> i
On Tue, 19 Dec 2023, Thomas Weißschuh wrote:
> Hi Luis and Julia,
>
> (Julia, there is a question and context for you inline, marked with your name)
>
> On 2023-12-18 13:21:49-0800, Luis Chamberlain wrote:
> > So we can split this up concentually in two:
> >
> > * constificaiton of the table ha
Hi Luis and Julia,
(Julia, there is a question and context for you inline, marked with your name)
On 2023-12-18 13:21:49-0800, Luis Chamberlain wrote:
> So we can split this up concentually in two:
>
> * constificaiton of the table handlers
> * constification of the table struct itself
>
> On
So we can split this up concentually in two:
* constificaiton of the table handlers
* constification of the table struct itself
On Sun, Dec 17, 2023 at 11:10:15PM +0100, Thomas Weißschuh wrote:
> The handlers can already be made const as shown in this series,
The series did already produce iss
On 2023-12-17 13:02:01+0100, Joel Granados wrote:
> Catching up with mail
>
> On Tue, Dec 12, 2023 at 11:51:30PM -0800, Luis Chamberlain wrote:
> > On Tue, Dec 12, 2023 at 10:09:30AM +0100, Joel Granados wrote:
> > > My idea was to do something similar to your originl RFC, where you have
> > >
Catching up with mail
On Tue, Dec 12, 2023 at 11:51:30PM -0800, Luis Chamberlain wrote:
> On Tue, Dec 12, 2023 at 10:09:30AM +0100, Joel Granados wrote:
> > My idea was to do something similar to your originl RFC, where you have
> > an temporary proc_handler something like proc_hdlr_const (we
On Fri, 15 Dec 2023, Thomas Weißschuh wrote:
> On 2023-12-12 23:51:30-0800, Luis Chamberlain wrote:
> > On Tue, Dec 12, 2023 at 10:09:30AM +0100, Joel Granados wrote:
> > > My idea was to do something similar to your originl RFC, where you have
> > > an temporary proc_handler something like proc
On 2023-12-12 23:51:30-0800, Luis Chamberlain wrote:
> On Tue, Dec 12, 2023 at 10:09:30AM +0100, Joel Granados wrote:
> > My idea was to do something similar to your originl RFC, where you have
> > an temporary proc_handler something like proc_hdlr_const (we would need
> > to work on the name) and
Luis Chamberlain writes:
> On Mon, Dec 11, 2023 at 12:25:10PM +0100, Thomas Weißschuh wrote:
>> Before sending it I'd like to get feedback on the internal rework of the
>> is_empty detection from you and/or Luis.
>>
>> https://git.sr.ht/~t-8ch/linux/commit/ea27507070f3c47be6febebe451bbb88f6ea707
On Tue, Dec 12, 2023 at 10:09:30AM +0100, Joel Granados wrote:
> My idea was to do something similar to your originl RFC, where you have
> an temporary proc_handler something like proc_hdlr_const (we would need
> to work on the name) and move each subsystem to the new handler while
> the others sta
On Mon, Dec 11, 2023 at 12:25:10PM +0100, Thomas Weißschuh wrote:
> Before sending it I'd like to get feedback on the internal rework of the
> is_empty detection from you and/or Luis.
>
> https://git.sr.ht/~t-8ch/linux/commit/ea27507070f3c47be6febebe451bbb88f6ea707e
> or the attached patch.
Pleas
On Mon, Dec 11, 2023 at 12:25:10PM +0100, Thomas Weißschuh wrote:
> On 2023-12-08 10:59:26+0100, Joel Granados wrote:
> > On Thu, Dec 07, 2023 at 08:19:43PM +0100, Thomas Weißschuh wrote:
> > > On 2023-12-07 11:43:57+0100, Joel Granados wrote:
>
> > [..]
>
> > > > I suggest you chunk it up with d
On 2023-12-08 10:59:26+0100, Joel Granados wrote:
> On Thu, Dec 07, 2023 at 08:19:43PM +0100, Thomas Weißschuh wrote:
> > On 2023-12-07 11:43:57+0100, Joel Granados wrote:
> [..]
> > > I suggest you chunk it up with directories in mind. Something similar to
> > > what I did for [4] where I divide
On Thu, Dec 07, 2023 at 08:19:43PM +0100, Thomas Weißschuh wrote:
> On 2023-12-07 11:43:57+0100, Joel Granados wrote:
> > Hey Thomas
> >
> > You have a couple of test bot issues for your 12/18 patch. Can you
> > please address those for your next version.
>
> I have these fixed locally, I assumed
On 2023-12-07 12:19:57+0100, Joel Granados wrote:
> On Tue, Dec 05, 2023 at 06:16:53PM +0100, Thomas Weißschuh wrote:
> > Hi Luis, Joel,
> >
> > On 2023-12-05 09:04:08+0100, Thomas Weißschuh wrote:
> > > On 2023-12-04 21:50:14-0800, Luis Chamberlain wrote:
> > > > On Mon, Dec 04, 2023 at 08:52:13A
On 2023-12-07 11:43:57+0100, Joel Granados wrote:
> Hey Thomas
>
> You have a couple of test bot issues for your 12/18 patch. Can you
> please address those for your next version.
I have these fixed locally, I assumed Luis would also pick them up
directly until I have a proper v2, properly should
On Tue, Dec 05, 2023 at 02:27:04PM -0800, Luis Chamberlain wrote:
> On Tue, Dec 05, 2023 at 06:16:53PM +0100, Thomas Weißschuh wrote:
> > Hi Luis, Joel,
> >
> > On 2023-12-05 09:04:08+0100, Thomas Weißschuh wrote:
> > > On 2023-12-04 21:50:14-0800, Luis Chamberlain wrote:
> > > > On Mon, Dec 04, 2
On Tue, Dec 05, 2023 at 06:16:53PM +0100, Thomas Weißschuh wrote:
> Hi Luis, Joel,
>
> On 2023-12-05 09:04:08+0100, Thomas Weißschuh wrote:
> > On 2023-12-04 21:50:14-0800, Luis Chamberlain wrote:
> > > On Mon, Dec 04, 2023 at 08:52:13AM +0100, Thomas Weißschuh wrote:
> > > > Tested by booting and
On Tue, Dec 05, 2023 at 09:04:08AM +0100, Thomas Weißschuh wrote:
> On 2023-12-04 21:50:14-0800, Luis Chamberlain wrote:
> > On Mon, Dec 04, 2023 at 08:52:13AM +0100, Thomas Weißschuh wrote:
> > > Tested by booting and with the sysctl selftests on x86.
> >
> > Can I trouble you to rebase on sysctl
Hey Thomas
You have a couple of test bot issues for your 12/18 patch. Can you
please address those for your next version.
On Mon, Dec 04, 2023 at 08:52:13AM +0100, Thomas Weißschuh wrote:
> Problem description:
>
> The kernel contains a lot of struct ctl_table throught the tree.
> These are very
On Tue, Dec 05, 2023 at 06:16:53PM +0100, Thomas Weißschuh wrote:
> Hi Luis, Joel,
>
> On 2023-12-05 09:04:08+0100, Thomas Weißschuh wrote:
> > On 2023-12-04 21:50:14-0800, Luis Chamberlain wrote:
> > > On Mon, Dec 04, 2023 at 08:52:13AM +0100, Thomas Weißschuh wrote:
> > > > Tested by booting and
Hi Luis, Joel,
On 2023-12-05 09:04:08+0100, Thomas Weißschuh wrote:
> On 2023-12-04 21:50:14-0800, Luis Chamberlain wrote:
> > On Mon, Dec 04, 2023 at 08:52:13AM +0100, Thomas Weißschuh wrote:
> > > Tested by booting and with the sysctl selftests on x86.
> >
> > Can I trouble you to rebase on sys
On 2023-12-04 21:50:14-0800, Luis Chamberlain wrote:
> On Mon, Dec 04, 2023 at 08:52:13AM +0100, Thomas Weißschuh wrote:
> > Tested by booting and with the sysctl selftests on x86.
>
> Can I trouble you to rebase on sysctl-next?
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git
On Mon, Dec 04, 2023 at 08:52:13AM +0100, Thomas Weißschuh wrote:
> Tested by booting and with the sysctl selftests on x86.
Can I trouble you to rebase on sysctl-next?
https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=sysctl-next
Luis
Problem description:
The kernel contains a lot of struct ctl_table throught the tree.
These are very often 'static' definitions.
It would be good to make the tables unmodifiable by marking them "const"
to avoid accidental or malicious modifications.
This is in line with a general effort to move as
33 matches
Mail list logo
