API changes / 2.6.21 sysctl changes

API changes / 2.6.21 sysctl changes

[Bernd Schubert]

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

Re: API changes / 2.6.21 sysctl changes

[Alexey Dobriyan]

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?

Re: API changes / 2.6.21 sysctl changes

[Bernd Schubert]

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

Re: API changes / 2.6.21 sysctl changes

[Alexey Dobriyan]

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.