Re: cpuset - question

[Paul Jackson]

Randy asked:
> Just for info, why is this in /dev at all, instead of, say,
> /sys ??

Daniel added:
> I'm not sure of the true answer; it is likely that CPUSETS was
> designed in the 2.4 timeframe and compatibility was preferred over the
> clean sysfs interface.

No .. cpusets was a fresh design for Linux 2.6.  The two primary
authors were Simon Derr of Bull and myself of SGI.  So far as I
know, Bull did not have Linux 2.4 precedents.  SGI had both Linux
2.4 precedents and Irix precedents.  I chose not to propose either
of these SGI precedent API's for the Linux mainline kernel.

Simon proposed the primary interface for the /dev/cpuset, and I gladly
joined him as his design was superior.  Simon had this file system
mounted under /proc, and Christoph Hellwig (our primary reviewer -
thanks!) objected, recommending /dev/cpuset as the mount point instead.

In Christoph's own words on May 13, 2004:

 - don't mount the filesystem in procfs.  the whole point of a new
   fs is to move away from the procfs mess!  /dev/cpuset/ sounds like
   a saner mtpnt.

In any case, there are two aspects to this question.  Should the
cpuset hierarchy be a separate virtual file system of its own, or part
of the sysfs file system?  Then, if it is separate, where should it
be mounted.

The separate file system for the cpuset hierarchy has been a
clear success, in my (no doubt biased) view.  It has its own rules
appropriate for the hierarchical cpu and node sets it is managing.
Even if we were starting this work now, I would enthusiastically
advocate having it as its own, separate file system.

Given that, the mount point becomes rather secondary in my view.

Christoph's proposal of /dev/cpuset, still seems reasonable and
adequate today.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@xxxxxxx> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/