2007-06-11 13:13:23

by Bernd Schubert

[permalink] [raw]
Subject: API changes / 2.6.21 sysctl changes

Hi,

in 2.6.21 register_sysctl_table(), struct ctl_table and probably something
else did change. Unfortunately so far I didn't figure out the "something
else".

Please, if generic interface modifications render all available documentation
in the web invalid, is it so hard to also write kernel api documentation then
(even if it so far does not exist in the Documentation/ dir)?

I mean the time overhead of thousands of coders digging through git commits is
huge, just because API changes are not properly documented.

E.g.: Documentation/api/sysctl.txt

Up to 2.6.20:
struct ctl_table_header *register_sysctl_table(ctl_table * table, int
insert_at_head);


Beginning with 2.6.21-rcX:
struct ctl_table_header *register_sysctl_table(ctl_table * table);

struct ctl_table:
removed entry struct proc_dir_entry *de
added entry ctl_table *parent

[Maybe also something like]

Additionaly to different functions calls, programmers also need to change ...


Thanks,
Bernd


Thanks,
Bernd


2007-06-11 15:40:46

by Alexey Dobriyan

[permalink] [raw]
Subject: Re: API changes / 2.6.21 sysctl changes

On Mon, Jun 11, 2007 at 03:13:12PM +0200, Bernd Schubert wrote:
> in 2.6.21 register_sysctl_table(), struct ctl_table and probably something
> else did change. Unfortunately so far I didn't figure out the "something
> else".

Do you have a problem porting your sysctls to newer kernels?

2007-06-11 16:00:00

by Bernd Schubert

[permalink] [raw]
Subject: Re: API changes / 2.6.21 sysctl changes

On Monday 11 June 2007 17:46:27 Alexey Dobriyan wrote:
> On Mon, Jun 11, 2007 at 03:13:12PM +0200, Bernd Schubert wrote:
> > in 2.6.21 register_sysctl_table(), struct ctl_table and probably
> > something else did change. Unfortunately so far I didn't figure out the
> > "something else".
>
> Do you have a problem porting your sysctls to newer kernels?

A little bit, yes. Well, I got it working, but I don't understand why I had to
do that whay.

I'm porting lustre to newer kernel versions and up to 2.6.20 the procfs/sysctl
logic was

1.) register_sysctl_table() -> creates /proc/sys/lnet

2.) create_proc_entry() -> add additional files in /proc/sys/lnet

With 2.6.21 creating additional entries in /proc/sys/lnet fails and I have to
first call "proc_mkdir("sys/lnet", NULL)". I did this proc_mkdir() call even
before the register_sysctl_table() call, hoping that its correct.

My guess is that register_sysctl_table() doesn't create /proc/sys/lnet
anymore, but I have now idea why. Either I did something wrong or its
intended.

Since I don't like guessing I ask for more documentation. However I think in
general, each interface change should be documented. Its just such a waste of
time of many people, just because one person doesn't want to spend additional
5 min to write what did change.

Thanks

2007-06-11 16:35:43

by Alexey Dobriyan

[permalink] [raw]
Subject: Re: API changes / 2.6.21 sysctl changes

On Mon, Jun 11, 2007 at 05:59:45PM +0200, Bernd Schubert wrote:
> On Monday 11 June 2007 17:46:27 Alexey Dobriyan wrote:
> > On Mon, Jun 11, 2007 at 03:13:12PM +0200, Bernd Schubert wrote:
> > > in 2.6.21 register_sysctl_table(), struct ctl_table and probably
> > > something else did change. Unfortunately so far I didn't figure out the
> > > "something else".
> >
> > Do you have a problem porting your sysctls to newer kernels?
>
> A little bit, yes. Well, I got it working, but I don't understand why I had to
> do that whay.
>
> I'm porting lustre to newer kernel versions and up to 2.6.20 the procfs/sysctl
> logic was
>
> 1.) register_sysctl_table() -> creates /proc/sys/lnet
>
> 2.) create_proc_entry() -> add additional files in /proc/sys/lnet

Glue all your ctl_table's in tree and register it with one call. See how
XFS does this: fs/xfs/linux-2.6/xfs_sysctl.c

> With 2.6.21 creating additional entries in /proc/sys/lnet fails and I have to
> first call "proc_mkdir("sys/lnet", NULL)". I did this proc_mkdir() call even
> before the register_sysctl_table() call, hoping that its correct.
>
> My guess is that register_sysctl_table() doesn't create /proc/sys/lnet
> anymore, but I have now idea why. Either I did something wrong or its
> intended.