On Tue, Apr 05, 2005 at 09:20:34AM -0400, Shailabh Nagar wrote: > >For the cello-based io controller we are developing we need to assign > >certain queue-reordering functions to each class. For instance, the > >cello paper defines a real-time reordeding, deadline reordering and > >best-effort reordering. But the rcfs interface only allows to set the > >limit and guarantee for a class, there is no [obvious] way to set a > >different parameter. Are there any plans to add this capability to > >rcfs? > > the share file, present in every class, was to contain the common set of > parameters of interest to all controllers. Hence this file is not > expected to be extensible to include the per-class params. > > You can use the /rcfs/taskclass/config interface to set per-controller > parameters. But this will apply to all the classes, not just one.
I know. So, are there any plans to add "uncommon" per class configuration to CKRM/RCFS? Is there a strong opposition against adding them? > >As I was trying to work around this problem, I attempted to use the > >class name to infer what the classified function should be (three > >classes is good enough of a test, for starters) - but I have > >discovered that the class name contains the mount point and the class > >type: /rcfs/taskclass/foo/bar, when I was really expecting only the > >significant part of the path "foo/bar", since the mountpoint can be > >anywhere and the class type can be obtained by other means. Is this > >deliberate, or it just happened and nobody had a reason to change it? > > The reason for using a fully qualified path serves to uniquely identify > a class. Admittedly, the mount point isn't necessary, but the classtype is. > > Why is the presence of a common prefix (the mount point) a problem for > the classification function you're writing ? It is not a problem, it just looks inelegant. Stripping one or two path elements make no difference... florin -- Don't question authority: they don't know either!
signature.asc
Description: Digital signature
