On Fri, 2006-10-13 at 17:09 -0700, Joel Becker wrote:
> On Fri, Oct 13, 2006 at 04:37:38PM -0700, Matt Helsley wrote:
> > > Sure it works. You have one per resource group. In
> > > resource_group_make_object(), you sysfs_mkdir() the sysfs file. There
> >
> > That's the easy part. Next we need to make the pid attribute whenever a
> > new task is created. And delete it when the task dies. And move it
> > around whenever it changes groups. Is there rename() support in /sys? If
> > not, would changes to allow rename() be acceptable (I'm worried it would
> > impact alot of assumptions made in the existing code)?
>
> No, you don't create a pid attribute per task. The sysfs file
> is literally your large attribute. So, instead of echoing a new pid to
> "/sys/kernel/config/ckrm/group1/pids", you echo to
> "/sys/ckrm/group1/pids". To display them all, you just cat
> "/sys/ckrm/group1/pids". It's exactly like the file you want in
> configfs, just located in a place where it is allowed.
Oh, sorry. I was still operating on the one-value-per-attribute
assumption. This indeed looks like it would work.
> > Consider that having two very similar (but not symlinked!) trees in
> > both /sys/ ... /res_group and /sys/kernel/config/res_group could be
> > rather confusing to userspace programmers and users alike.
>
> Not really. It's not identical (tons of attributes live in the
> configfs part but not the sysfs part), and it has a clear deliniation of
> what each does.
Clear delineation to who? I'm not convinced this is any less confusing
to a userspace programmer than parsing a single newline between multiple
values in a configfs attribute.
> > It would be strange because when you rmdir a group
> > in /sys/kernel/config/res_group... a directory in /sys would also
> > disappear. Yet you can't mkdir or rmdir the /sys dirs. And to edit the
>
> This is no different than tons of sysfs and procfs functionality
> today.
Yup.
> > There are two parts to the complexity: code complexity and the number
> > of userspace pieces to deal with. I think that in both of these
> > categories the OVPA approach is more complex. Here's how I see it:
>
> By your definition, sysfs, configfs, and other fs-style control
> mechanisms are too complex. We should all just be using ioctl() so that
> coders and users have only one namespace :-)
That's an absurd conclusion to draw from my argument that one
filesystem-based approach is less complex than another.
> > > You're effectively suggesting that a specific attribute type of
> > > "repeated value of type X". No mixed types, no exploded structures,
> > > just a "list of this attr" sort of thing. This does fit my personal
> > > requirement of avoiding a generic, abusable system.
> >
> > Exactly.
>
> How do you implement it? Full on seq_file with restrictions
> (ops->start,stop,next,show)?
That was the plan.
Cheers,
-Matt Helsley
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech
