diff mbox series

[f2fs-dev] f2fs: make kobj_type structures constant

Message ID 20230209-kobj_type-f2fs-v1-1-b6feedbdd4a8@weissschuh.net (mailing list archive)
State Accepted
Commit 663bb23cc1ac1a4a3dad9282391706cf61b1f5a6
Headers show
Series [f2fs-dev] f2fs: make kobj_type structures constant | expand

Commit Message

Thomas Weißschuh Feb. 9, 2023, 3:20 a.m. UTC
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 <linux@weissschuh.net>
---
 fs/f2fs/sysfs.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)


---
base-commit: 0983f6bf2bfc0789b51ddf7315f644ff4da50acb
change-id: 20230209-kobj_type-f2fs-ba2302c4b920

Best regards,

Comments

patchwork-bot+f2fs@kernel.org Feb. 10, 2023, 9:40 p.m. UTC | #1
Hello:

This patch was applied to jaegeuk/f2fs.git (dev)
by Jaegeuk Kim <jaegeuk@kernel.org>:

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 <linux@weissschuh.net>
> 
> [...]

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!
Chao Yu Feb. 13, 2023, 9:25 a.m. UTC | #2
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 <linux@weissschuh.net>

Reviewed-by: Chao Yu <chao@kernel.org>

Thanks,
Jaegeuk Kim Feb. 13, 2023, 5:51 p.m. UTC | #3
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 <linux@weissschuh.net>
> 
> Reviewed-by: Chao Yu <chao@kernel.org>

Hi Chao,

Note that, next time, I won't apply/modify any patches merged in -dev,
unless it has a problem.

Thanks,

> 
> Thanks,
Chao Yu Feb. 14, 2023, 1:42 a.m. UTC | #4
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 <linux@weissschuh.net>
>>
>> Reviewed-by: Chao Yu <chao@kernel.org>
> 
> 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,
Jaegeuk Kim Feb. 14, 2023, 6:07 p.m. UTC | #5
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 <linux@weissschuh.net>
> > > 
> > > Reviewed-by: Chao Yu <chao@kernel.org>
> > 
> > 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,
Chao Yu Feb. 15, 2023, 2:43 p.m. UTC | #6
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 <linux@weissschuh.net>
>>>>
>>>> Reviewed-by: Chao Yu <chao@kernel.org>
>>>
>>> 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,
Jaegeuk Kim Feb. 15, 2023, 5:46 p.m. UTC | #7
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 <linux@weissschuh.net>
> > > > > 
> > > > > Reviewed-by: Chao Yu <chao@kernel.org>
> > > > 
> > > > 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,
diff mbox series

Patch

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,