Messages in this thread | | | Subject | Re: [ckrm-tech] [PATCH 0/5] Allow more than PAGESIZE data read in configfs | From | Matt Helsley <> | Date | Sat, 14 Oct 2006 18:06:26 -0700 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |