lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20061030062332.856dcc32.pj@sgi.com>
Date:	Mon, 30 Oct 2006 06:23:32 -0800
From:	Paul Jackson <pj@....com>
To:	Pavel Emelianov <xemul@...nvz.org>
Cc:	vatsa@...ibm.com, dev@...nvz.org, sekharan@...ibm.com,
	menage@...gle.com, ckrm-tech@...ts.sourceforge.net,
	balbir@...ibm.com, haveblue@...ibm.com,
	linux-kernel@...r.kernel.org, matthltc@...ibm.com,
	dipankar@...ibm.com, rohitseth@...gle.com, devel@...nvz.org
Subject: Re: [ckrm-tech] [RFC] Resource Management - Infrastructure choices

Pavel wrote:
> 1. One of the major configfs ideas is that lifetime of
>    the objects is completely driven by userspace.
>    Resource controller shouldn't live as long as user
>    want. It "may", but not "must"!

I had trouble understanding what you are saying here.

What does the phrase "live as long as user want" mean?


> 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".
>
> 3. Configfs may be easily implemented later as an additional
>    interface. I propose the following solution:
>      - First we make an interface via any common kernel
>        facility (syscall, ioctl, etc);
>      - Later we may extend this with configfs. This will
>        alow one to have configfs interface build as a module.

So you would add bloat to the kernel, with two interfaces
to the same facility, because you don't want the resource
controller to depend on configfs.

I am familiar with what is wrong with kernel bloat.

Can you explain to me what is wrong with having resource
groups depend on configfs?  Is there something wrong with
configfs that would be a significant problem for some systems
needing resource groups?

It is better where possible, I would think, to reuse common
infrastructure and minimize redundancy.  If there is something
wrong with configfs that makes this a problem, perhaps we
should fix that.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ