Message-Id: <200806111943.42390.tomasz@grobelny.oswiecenia.net>
Date:	Wed, 11 Jun 2008 19:43:42 +0200
From:	Tomasz Grobelny <tomasz@...belny.oswiecenia.net>
To:	Gerrit Renker <gerrit@....abdn.ac.uk>, acme@...hat.com
Cc:	dccp@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 1/1] [DCCP][QPOLICY]: Make information about qpolicies available to userspace

Dnia Tuesday 10 of June 2008, Gerrit Renker napisał:
> | > But since it is about dynamic runtime configuration, how about using
> | > sysfs or configfs instead? This is a brainstorming question, I think
> | > that sysfs is generally preferred. I don't know how well configfs has
> | > taken off, it is similar, but needs to be added in the configuration
> | > (under Pseudeo Filesystems, CONFIG_CONFIGFS_FS=y|m)
> | > http://lwn.net/Articles/148973/ and Documentation/filesystems/configs.
> | > But this could be done later as well.
> |
> | procfs has some fine example of being used for this kind of information,
> | namely /proc/cpuinfo and /proc/meminfo
> |
> | sysfs: from sysfs-rules.txt: "(...) the sysfs interface cannot provide a
> | stable interface (...)"
>
> Yes that is a key point and I think we are talking about the same point
> here.
>
> I had mentioned sysfs/procfs as alternatives not because they are the best
> possible match, but since it shows that similar problems (and likely
> solutions) exist also in other areas.
>
That's ok, I just mention what I know about them so that we can have complete 
argumentation for/against given solution.

> But there are also areas where the rate of change is relatively low or
> even absent: Documentation/ABI/README for instance mentions 4 different
> levels of stability (stable/testing/obsolete/removed), the most entries
> are under `testing'.
>
This one should probably be marked as testing too. And probably be moved to 
stable with time (when it proves useful for applications).

> | configfs is for configuring kernel from userspace. Which is quite
> | opposite to what we want.
>
> Ok I think I understand now where you are heading - but then we can go a
> much simpler route: why not implement a sysctl (which is also mirrored in
> /proc/sys) that contains all available/implemented qpolicies as a
> space-separated string, such as
>
> 	cat /proc/sys/net/ipv4/tcp_available_congestion_control ?
>
Could be /proc/sys. I just had an impression that sysctls are for setting 
certain variables used in kernel. But as far as I understand it the 
difference is highly subjective and I'm ok with both /proc and /proc/sys. 
Would be nice to have more opinions (Arnaldo? others?) whether we should 
favour one over other.

> And I think that it is unnecessarily complex to add the available
> parameters belonging to each qpolicy as well.
>
I think it is critical. If the application just wants to know which qpolicies 
are available it can try to set it with setsockopt(). If it gets an error 
given qpolicy is unavailable. As simple as that. No need for additional 
interface.
But if the application wants information about implemented parameters there is 
currently no way to get it. It can try to send() packet and check return 
value (which is quite a hack to be honest). It will work if the parameter is 
not implemented at all. But what happens when you try to set priority for a 
packet and use "simple" qpolicy? AFAIR nothing - you get no information 
whatsoever that this parameter will not be used inside qpolicy.

And that's why we need information about parameters in /proc or /proc/sys.

> If we agree on using unique strings to identify qpolicies then we can
> keep the runtime discovery much simpler. I think a manpage would be more
> helpful here, since the runtime discovery of parameters is not
> immediately obvious.
>
Manpage of what? Documentation is certainly needed but before writing one we 
need to have a basic implementation we agree upon.
-- 
Regards,
Tomasz Grobelny
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists