Messages in this thread | | | Date | Thu, 28 Feb 2008 19:22:32 -0600 | From | Paul Jackson <> | Subject | Re: [RFC] Prefixing cgroup generic control filenames with "cgroup." |
| |
> Subsystem-created files already have an appropriate prefix.
Good ... such little consistencies in naming are helpful, when voluntarily self imposed, without incompatible changes to published names.
> > No need to > > change the existing well known names for this reason. > > But that's part of my point - is it reasonable to describe a system > that was only introduced in 2.6.24 as "well-known"?
In their earlier cpuset context, "tasks" and "notify_on_release" have been well known for years.
And breaking actual compatibility, in a way that will break more than the tiniest set of users, even over one release, should not be done without both (1) a really good cause, and (2) a plan for migrating users over a couple of releases to the new interface.
> > back much earlier than that. Please don't rename these two files in > > cgroups; and of course absolutely don't rename them in cpusets. > > No, I wasn't planning to make any changes to cpusets.
Yeah - I figured you wouldn't risk my wrath changing this in cpusets ;).
Could you please not change them in cgroups, either?
> > Please don't end up with different names of these files, depending on > > whether you're in cgroups or cpusets, either. > > That already happens - when mounted as the "cpuset" filesystem, we > have names like "mems_allowed". When mounted as cgroups, we have names > like cpuset.mems_allowed.
Ok - it does make sense that cpuset specific files, when embedded in the more general purpose cgroups, are adorned with name prefixes that they didn't have in the legacy API. And besides, it is what is -- we released it, and there's no compelling disaster forcing a change.
But generic cgroup infrastructure files, such as "tasks", have not had such adornments. And now, that is what it is -- released, and sufficient to remain as it is.
> No, I don't like that idea either.
Good (and extra credit for saying so with fewer words and more politely than I managed ;).
-- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.940.382.4214
| |