I don't see the mixing of kernel generated filenames with user
generated names to be a practical problem. There just aren't that many
names in play here.
I'd think that renaming even the few cgroup files that were published
in 2.6.24 would be a fairly unacceptable incompatibility.
Paul M wrote:
We could accomplish that much by decreeing that future new kernel
generated names that we might add follow some stronger convention,
such as the cgroup_ or appropriate subsystem prefix. No need to
change the existing well known names for this reason.
Serge wrote:
Agreed.
Paul M wrote:
Yuck. You're complicating this more than necessary, to solve a problem
that exists only in your imagination ;). Simple, overlapping,
namespaces really are ok, so long as the number of distinct names and
the rate of their growth are sufficiently low.
Just set some convention for future added names; that's enough to enable
others adding user space names to avoid collisions. Such as using only
lower case letters and underscores, or the cgroup_ or other prefix
on -future- names. That's sufficient, if not more than sufficient.
That's sufficient reason. Actually, in terms of 'common names used
by humans' some of these names, "tasks" and "notify_on_release", date
back much earlier than that. Please don't rename these two files in
cgroups; and of course absolutely don't rename them in cpusets.
Please don't end up with different names of these files, depending on
whether you're in cgroups or cpusets, either.
Andrew, looking at a tree that Paul M drew, wrote:
Not to me ;) Yuck.
Andrew wrote:
Lordy lordy -- a bunch of intrusive, complicating crap to solve a
non-existent problem (sorry for the indelicate choice of words ;).
that could work
Unnecessary complication. No need to burden our children and grand children
with this special case, forever after, in order to solve some empty set of
special cases currently facing us.
I'll keep a bucket of ice water handy, for that patch ;). One nice
property of the cpuset file system is that there is exactly one
directory per cpuset. The kernel creates regular files; the user
creates directories; no exceptions. I encourage us to keep that state
of affairs, for both cgroups and cpusets.
I probably won't insist on a full force NAK so long as cpusets are
unchanged, thanks to such compatibility measures; though I would be
tempted to ... if I could think of a sufficient reason.
Human beings really don't have problems with overlapping name spaces
like this; to them it seems simpler in many cases, such as this one.
This has been, in my (biased and less than humble) view, one of the
successes of the cpuset interface. It's just enough to comfortably do
what's needed; not some overly formalized and unnecessarily robust
complication beyond what's practically needed. More people can
comfortably understand it this way.
Design interfaces, and write code, for humans. Resists making
concessions to the limitations of computers (or our fellow geeks) as
best you can, whenever you can.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.940.382.4214
--
