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 dccp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
