On Wed, 2006-11-01 at 11:01 +0300, Pavel Emelianov wrote:
> [snip]
>
> >> 2. Having configfs as the only interface doesn't alow
> >> people having resource controll facility w/o configfs.
> >> Resource controller must not depend on any "feature".
That's not true. It's possible for a resource control system that uses
a filesystem interface to operate without it's filesystem interface. In
fact, for performance reasons I think it's necessary.
Even assuming your point is true, since you agree there should be only
one interface does it matter that choosing one prevents implementing
another?
Why must a resource controller never depend on another "feature"?
> > One flexibility configfs (and any fs-based interface) offers is, as Matt
> > had pointed out sometime back, the ability to delage management of a
> > sub-tree to a particular user (without requiring root permission).
> >
> > For ex:
> >
> > /
> > |
> > -----------------
> > | |
> > vatsa (70%) linux (20%)
> > |
> > ----------------------------------
> > | | |
> > browser (10%) compile (50%) editor (10%)
> >
> > In this, group 'vatsa' has been alloted 70% share of cpu. Also user
> > 'vatsa' has been given permissions to manage this share as he wants. If
> > the cpu controller supports hierarchy, user 'vatsa' can create further
> > sub-groups (browser, compile ..etc) -without- requiring root access.
>
> I can do the same using bcctl tool and sudo :)
bcctl and, to a lesser extent, sudo are more esoteric.
Open, read, write, mkdir, unlink, etc. are all system calls so it seems
we all agree that system calls are the way to go. ;) Now if only we
could all agree on which system calls...
> > Also it is convenient to manipulate resource hierarchy/parameters thr a
> > shell-script if it is fs-based.
> >
> >> 3. Configfs may be easily implemented later as an additional
> >> interface. I propose the following solution:
> >
> > Ideally we should have one interface - either syscall or configfs - and
> > not both.
To incorporate all feedback perhaps we should replace "configfs" with
"filesystem".
Cheers,
-Matt Helsley
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
