Messages in this thread | | | From | Kay Sievers <> | Date | Thu, 2 Jun 2011 15:24:11 +0200 | Subject | Re: [PATCH] sysctl: add support for poll() |
| |
On Thu, Jun 2, 2011 at 15:12, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: >> > Or to manage it properly. >> >> What if the user decides do invoke sethostname syscall "by hand"? >> Hostname would change beneath any other process that is trying to >> manage it properly. What this patch does is to notify that process >> that something happened. > > That is a stupid argument. Shall we extend it to its logical idiotic end > and ask > > "What if the user decides to recompile their kernel without sysfs poll > support ?"
Alan please! This is not something we haven't thought through.
> You have to be root to run sethostname, at which point you are > realistically at the command line, a superuser and you know what you are > doing (eg using sethostname for non IP network naming, or cluster id, or > other stuff).
Please stay to the actual problem this patch tries to resolve.
>> With this patch in, if anyone wants to manage a file under /proc/sys >> there's really a small amount of code to write. He only has to define >> the new poll struct for that file. > > Sure - and there is an 8 byte cost per sysctl node (of which we have > rather a lot), and we really need to tackle sysfs not sysctl anyway.
It is. And we will very likely need poll() for other things in /proc/sys too. It's the cost of providing functionality we just need today.
I could understand arguing about things like: void *extra1; void *extra2; in that very same structure, but not about something that can't really be solved otherwise.
> I'm not averse to pollable sysfs/sysctl nodes at all although the memory > hit on sysfs is going to be tricky to manage and need clever code.
Yeah, but not related to the problem this patch tries to solve.
> I just think the utsname is a completely misguided example and whoever is > trying to do it doesn't actually understand the limits of utsname.
We are not talking about limits of a certain infrastructure. It is used, it will not go away, we need to support it.
This is about propagating in-kernel state changes to userspace. Please open a different conversation for everything else.
Thanks, Kay
| |