> In my understanding slicable and allocable are synonyms.
Seems strange. This definition devalues/reduces the word "sliceable"
from its intuitive and historical meaning. I think that's a bad
idea in terms of documentation and clarity.
But, the result is that you and I agree about what resources are sliceable.
> I may slice a
> resource by handing it all to you, virtualizing some set of resources
> and handing them to you, or scheduling your use so they don't interfere
> with others. That's a pretty wide range of techniques swallowed up in
> one word, but I understand slicing to imply an allocation of resources
> isolated temporally, spatially, or virtually.
Good, we agree (except for the definition of the word).
> Slicable doesn't necessarily mean programmable to me. If I'm allocated
> half the capacity of a link, that doesn't mean I get to program the
> controller, but the link's been sliced.
Right. Programmable is orthogonal.
> If I understand your example above of unslicable virtual resources
> above, I think they're still slicable by my broader definition: I could
> give them to another researcher as a whole. I understand that they're
> probably not further virtualizable.
> By talking about resources that slicable by that definition, RSpecs talk
> about anything a user could ask to be given or that a component can
> allocate. That seems like a small, clean thing to describe, and it's
> what I think RSpecs are for.
Sounds like we're in violent agreement.
But via your many examples it seems that your "sliceable" has now
lost all its semantics.
> Even if we disagree on "slicable" do you
> believe the goal of describing resources researchers can ask for and
> receive?
Absolutely.
_______________________________________________
substrate-wg mailing list
substrate-wg@...
http://lists.geni.net/mailman/listinfo/substrate-wg
