Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.")
the driver core allows the usage of const struct kobj_type.
Take advantage of this to constify the structure definitions to prevent
modification at runtime.
Signed-off-by: Thomas Weißschuh <[email protected]>
---
fs/f2fs/sysfs.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c
index 83a366f3ee80..43f1ff1b92ba 100644
--- a/fs/f2fs/sysfs.c
+++ b/fs/f2fs/sysfs.c
@@ -1129,13 +1129,13 @@ static const struct sysfs_ops f2fs_attr_ops = {
.store = f2fs_attr_store,
};
-static struct kobj_type f2fs_sb_ktype = {
+static const struct kobj_type f2fs_sb_ktype = {
.default_groups = f2fs_groups,
.sysfs_ops = &f2fs_attr_ops,
.release = f2fs_sb_release,
};
-static struct kobj_type f2fs_ktype = {
+static const struct kobj_type f2fs_ktype = {
.sysfs_ops = &f2fs_attr_ops,
};
@@ -1143,7 +1143,7 @@ static struct kset f2fs_kset = {
.kobj = {.ktype = &f2fs_ktype},
};
-static struct kobj_type f2fs_feat_ktype = {
+static const struct kobj_type f2fs_feat_ktype = {
.default_groups = f2fs_feat_groups,
.sysfs_ops = &f2fs_attr_ops,
};
@@ -1184,7 +1184,7 @@ static const struct sysfs_ops f2fs_stat_attr_ops = {
.store = f2fs_stat_attr_store,
};
-static struct kobj_type f2fs_stat_ktype = {
+static const struct kobj_type f2fs_stat_ktype = {
.default_groups = f2fs_stat_groups,
.sysfs_ops = &f2fs_stat_attr_ops,
.release = f2fs_stat_kobj_release,
@@ -1211,7 +1211,7 @@ static const struct sysfs_ops f2fs_feature_list_attr_ops = {
.show = f2fs_sb_feat_attr_show,
};
-static struct kobj_type f2fs_feature_list_ktype = {
+static const struct kobj_type f2fs_feature_list_ktype = {
.default_groups = f2fs_sb_feat_groups,
.sysfs_ops = &f2fs_feature_list_attr_ops,
.release = f2fs_feature_list_kobj_release,
---
base-commit: 0983f6bf2bfc0789b51ddf7315f644ff4da50acb
change-id: 20230209-kobj_type-f2fs-ba2302c4b920
Best regards,
--
Thomas Weißschuh <[email protected]>
Hello:
This patch was applied to jaegeuk/f2fs.git (dev)
by Jaegeuk Kim <[email protected]>:
On Thu, 09 Feb 2023 03:20:10 +0000 you wrote:
> Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.")
> the driver core allows the usage of const struct kobj_type.
>
> Take advantage of this to constify the structure definitions to prevent
> modification at runtime.
>
> Signed-off-by: Thomas Weißschuh <[email protected]>
>
> [...]
Here is the summary with links:
- [f2fs-dev] f2fs: make kobj_type structures constant
https://git.kernel.org/jaegeuk/f2fs/c/663bb23cc1ac
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
On 2023/2/9 11:20, Thomas Weißschuh wrote:
> Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.")
> the driver core allows the usage of const struct kobj_type.
>
> Take advantage of this to constify the structure definitions to prevent
> modification at runtime.
>
> Signed-off-by: Thomas Weißschuh <[email protected]>
Reviewed-by: Chao Yu <[email protected]>
Thanks,
On 02/13, Chao Yu wrote:
> On 2023/2/9 11:20, Thomas Wei?schuh wrote:
> > Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.")
> > the driver core allows the usage of const struct kobj_type.
> >
> > Take advantage of this to constify the structure definitions to prevent
> > modification at runtime.
> >
> > Signed-off-by: Thomas Wei?schuh <[email protected]>
>
> Reviewed-by: Chao Yu <[email protected]>
Hi Chao,
Note that, next time, I won't apply/modify any patches merged in -dev,
unless it has a problem.
Thanks,
>
> Thanks,
On 2023/2/14 1:51, Jaegeuk Kim wrote:
> On 02/13, Chao Yu wrote:
>> On 2023/2/9 11:20, Thomas Weißschuh wrote:
>>> Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.")
>>> the driver core allows the usage of const struct kobj_type.
>>>
>>> Take advantage of this to constify the structure definitions to prevent
>>> modification at runtime.
>>>
>>> Signed-off-by: Thomas Weißschuh <[email protected]>
>>
>> Reviewed-by: Chao Yu <[email protected]>
>
> Hi Chao,
>
> Note that, next time, I won't apply/modify any patches merged in -dev,
> unless it has a problem.
Hi Jaegeuk,
Oh, any particular reason, to avoid unneeded commit id change when the time is
close to merge window?
Is there any period of grace before merging patches from dev-test branch into dev
branch? Maybe a week is reasonable? so I may have time to catch up in time.
Thanks,
>
> Thanks,
>
>>
>> Thanks,
On 02/14, Chao Yu wrote:
> On 2023/2/14 1:51, Jaegeuk Kim wrote:
> > On 02/13, Chao Yu wrote:
> > > On 2023/2/9 11:20, Thomas Wei?schuh wrote:
> > > > Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.")
> > > > the driver core allows the usage of const struct kobj_type.
> > > >
> > > > Take advantage of this to constify the structure definitions to prevent
> > > > modification at runtime.
> > > >
> > > > Signed-off-by: Thomas Wei?schuh <[email protected]>
> > >
> > > Reviewed-by: Chao Yu <[email protected]>
> >
> > Hi Chao,
> >
> > Note that, next time, I won't apply/modify any patches merged in -dev,
> > unless it has a problem.
>
> Hi Jaegeuk,
>
> Oh, any particular reason, to avoid unneeded commit id change when the time is
> close to merge window?
Hi Chao,
I'm trying to avoid breaking the -next branch.
>
> Is there any period of grace before merging patches from dev-test branch into dev
> branch? Maybe a week is reasonable? so I may have time to catch up in time.
No rule, but I'm trying to wait for several days while running my local tests.
If the patch looks okay, sometimes I'll queue it right away.
Thanks,
>
> Thanks,
>
> >
> > Thanks,
> >
> > >
> > > Thanks,
On 2023/2/15 2:07, Jaegeuk Kim wrote:
> On 02/14, Chao Yu wrote:
>> On 2023/2/14 1:51, Jaegeuk Kim wrote:
>>> On 02/13, Chao Yu wrote:
>>>> On 2023/2/9 11:20, Thomas Weißschuh wrote:
>>>>> Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.")
>>>>> the driver core allows the usage of const struct kobj_type.
>>>>>
>>>>> Take advantage of this to constify the structure definitions to prevent
>>>>> modification at runtime.
>>>>>
>>>>> Signed-off-by: Thomas Weißschuh <[email protected]>
>>>>
>>>> Reviewed-by: Chao Yu <[email protected]>
>>>
>>> Hi Chao,
>>>
>>> Note that, next time, I won't apply/modify any patches merged in -dev,
>>> unless it has a problem.
>>
>> Hi Jaegeuk,
>>
>> Oh, any particular reason, to avoid unneeded commit id change when the time is
>> close to merge window?
>
> Hi Chao,
>
> I'm trying to avoid breaking the -next branch.
Jaegeuk, so why do we need to avoid breaking -next branch? I didn't get it. :-(
>
>>
>> Is there any period of grace before merging patches from dev-test branch into dev
>> branch? Maybe a week is reasonable? so I may have time to catch up in time.
>
> No rule, but I'm trying to wait for several days while running my local tests.
> If the patch looks okay, sometimes I'll queue it right away.
Sure, not problem.
Thanks,
>
> Thanks,
>
>>
>> Thanks,
>>
>>>
>>> Thanks,
>>>
>>>>
>>>> Thanks,
On 02/15, Chao Yu wrote:
> On 2023/2/15 2:07, Jaegeuk Kim wrote:
> > On 02/14, Chao Yu wrote:
> > > On 2023/2/14 1:51, Jaegeuk Kim wrote:
> > > > On 02/13, Chao Yu wrote:
> > > > > On 2023/2/9 11:20, Thomas Wei?schuh wrote:
> > > > > > Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.")
> > > > > > the driver core allows the usage of const struct kobj_type.
> > > > > >
> > > > > > Take advantage of this to constify the structure definitions to prevent
> > > > > > modification at runtime.
> > > > > >
> > > > > > Signed-off-by: Thomas Wei?schuh <[email protected]>
> > > > >
> > > > > Reviewed-by: Chao Yu <[email protected]>
> > > >
> > > > Hi Chao,
> > > >
> > > > Note that, next time, I won't apply/modify any patches merged in -dev,
> > > > unless it has a problem.
> > >
> > > Hi Jaegeuk,
> > >
> > > Oh, any particular reason, to avoid unneeded commit id change when the time is
> > > close to merge window?
> >
> > Hi Chao,
> >
> > I'm trying to avoid breaking the -next branch.
>
> Jaegeuk, so why do we need to avoid breaking -next branch? I didn't get it. :-(
That's not for linux-next, but my -next work.
>
> >
> > >
> > > Is there any period of grace before merging patches from dev-test branch into dev
> > > branch? Maybe a week is reasonable? so I may have time to catch up in time.
> >
> > No rule, but I'm trying to wait for several days while running my local tests.
> > If the patch looks okay, sometimes I'll queue it right away.
>
> Sure, not problem.
>
> Thanks,
>
> >
> > Thanks,
> >
> > >
> > > Thanks,
> > >
> > > >
> > > > Thanks,
> > > >
> > > > >
> > > > > Thanks,