Re: sysctl in 2.6.24.2 excludes unapproved files from /proc/sys?

[Peter T. Breuer]

"Also sprach Alexey Dobriyan:"
> On 3/1/08, Peter T. Breuer <ptb@xxxxxxxxxxxxxx> wrote:
> > A change in 2.6.24.x kernel/sysctl.c seems to exclude exo-kernel drivers
> > from using the /proc/sys/ interface:
> 
> That's somewhat correct.

OK.  Thanks.  That's a relief.  It's always good to know that it's the
universe that's crazy, not me.

> > What's a person to do?
> 
> If I understand you correcty, the answer is drop '.ctl_name' bits from
> new sysctls and make sure common parts of tables match the ones
> in mainline.

You are saying, O wise delphic oracle, that I *can* add stuff in the
/proc/sys tree, provided it's at an approved leaf?  Or that I must use
CTL_UNNUMBERED for flipping efferything, not just most things?  (one
would have thought one was entitled to number things in ones own
subdirectories, failing some comment to the contrary).  I tried
CTL_UNNUMBERED at least on my top level directory, and didn't add any
entries to it, and THAT failed. So on the face of it that
interpretation of your words cannot be correct.

/proc/sys/dev is where I am trying to add a directory, because I am none
of

        { DEV_CDROM,    "cdrom",        trans_cdrom_table },
        { DEV_PARPORT,  "parport",      trans_parport_table },
        { DEV_RAID,     "raid",         trans_raid_table },
        { DEV_MAC_HID,  "mac_hid",      trans_mac_hid_files },
        { DEV_SCSI,     "scsi",         trans_scsi_table },
        { DEV_IPMI,     "ipmi",         trans_ipmi_table },

and those are the legal entries at the moment, and I can't see any
commonality in or among any of those or between them and me. 

That's not a leaf.  However, none of its eventual leaves have anything
to do with my driver.  So here in dev/ would be just fine to plonk a new
device driver subtree, methinks.

And you want me to use CTL_UNNUMBERED for everything in my subtree
from where it branches off?

OK. I'm game. I'll try. I've tried a lot of other things over the past
few days.

And how am I supposed to maintain this driver, now that it's full of
#iffoo < 2.6.24 every two lines?

And while I am here, what's the purpose of this change? What's the
point of checking that only the pre-approved entries to this tree are
made? I don't get it! If you don't want somebody adding something
to /proc/sys just delete their registration call from the kernel
tree, surely! Is this some sort of in-kernel fight? Defenders of
/proc/sys against attackers? Is the problem that one can't persuade
some maintainers to stop their authors from adding to /proc/sys, so
instead it's been made it necessary to ask permission of the /proc/sys
maintainer instead via this change?

Now every author has to make a change in their code AND make a change in
the sysctl code in a totally different part of the kernel when they want
a single change - adding a file or dir to their file hierarchy.

And what's the registration function for, now that the details are
largely there in sysctl.c and sysctl_check.c? It just adds detail
like strategy and proc_handler? And says when to put up and tear down
the subtree in question? Why not move ALL the detail over to
kernel/sysctl.c too!

(if you think I think it's crazy, yes, you are not so crazy).

Peter








 



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/