[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m17io3z8o2.fsf@ebiederm.dsl.xmission.com>
Date: Fri, 10 Aug 2007 09:55:09 -0600
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, Alexey Dobriyan <adobriyan@...ru>,
axboe@...nel.dk
Subject: Re: [PATCH 08/10] sysctl: Remove broken cdrom binary sysctls
Alan Cox <alan@...rguk.ukuu.org.uk> writes:
> On Thu, 09 Aug 2007 19:01:14 -0600
> ebiederm@...ssion.com (Eric W. Biederman) wrote:
>
>>
>> The binary interface for the cdrom sysctls can't possilby work.
>> So remove the binary sysctls and update the test for finding
>> out which sysctl table entry we are dealy with to use the procname
>> and not the ctl_name (which I am removing).
>
> NAK
>
> I've no problem with the basic idea of removing the names from user
> space, but you've just demonstrated with the patch below that it causes
> some quite revolting changes for the bad in code which previously was
> nicely done switch statements and is now a nest of string compares and
> inline code.
>
> There are very good reasons to have a cookie in the sysctl entry for
> internal use and which is private to the subsystem using the sysctl (ie
> not for sysctl() use and not neccessarily unique).
Sure. We currently have 3 fields for that: data, extra1, and extra2.
You need to cast them to get an integer values but their definition
especially extra1 and extra2 are left up to the caller.
In that code we could just do a test on valp (i.e. data in struct
ctl_table).
I just wanted something stupid and simple, so the -mm tree would not
be full of broken sysctls.
At least to my eyes the code doesn't look much worse. But if you
want to do something better feel free.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists