"Eric Van Hensbergen" <[email protected]> writes:
> On 7/23/07, Latchesar Ionkov <[email protected]> wrote:
>> It doesn't really matter (for me) whether it is sysctl or sysfs
>> interface. The sysctl approach seemed easier to implement. If the
>> consensus is to use sysfs, I'll send a patch (for 2.6.24).
>>
>> Sorry for the incorrect implementation, I guess I stole the code from
>> unappropriate place :)
>>
>
> I think this is appropriate for a "fix" submission to the 2.6.23-rc
> series. If you don't have the bandwidth right now, I'll look at
> reworking it, or at the very least just removing the sysctl interface.
For something this simple I don't see a problem with using sysctl
as it is simple and stupid, and generally easy to implement. If you
had value per filesystem you would want things as mount options or
someplace else but for a global tunable sysctl is decent (although it
doesn't do much for locking).
The practical issue is that sysctl has two places it shows up.
/proc/sys/... (very unix/plan9 ish)
sys_sysctl() (not very unixish and not barely used).
Currently allocating binary numbers so you can use the sys_sysctl
interface is not required. And it doesn't look interesting in your
case.
So all I'm asking is that you don't allocate binary numbers for
sys_sysctl. As odds are no one is going to use them anyway.
The binary numbers you are using were not reserved in sysctl.h
so they were not reserved properly (a bug).
My patch simply removes the attempt to provide binary numbers for
sys_sysctl(), but keeps the good unixish /proc/sys parts.
If sysfs provides some cool widgetry that really helps go for it
but I would actually be surprised in this context if it does.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]