[Click] "Graft" ports

[Cliff Frey]

Eddie very recently made changes to the parser, allowing for new syntax and
types of connections, so I would look at his recent commits.

Cliff

On Fri, Jan 28, 2011 at 11:05 AM, Philip Prindeville <
philipp_subx at redfish-solutions.com> wrote:

> On 1/21/11 6:48 PM, Eddie Kohler wrote:
>
>> On 01/21/2011 05:42 PM, Philip Prindeville wrote:
>>
>>> The original concern (with exposing global objects into the guts of an
>>> elementclass) was that this would only work for a single instance is
>>> valid...
>>> that is, if A imports B, then you can only have a single object of class
>>> A.
>>>
>>
>> No, you could have many.  But any element of class A will refer to the
>> same imported element.  Sometimes that's not what you want.  Sometimes it
>> is.
>>
>> The idea of "default connections" is interesting -- "include this
>> connection only if the port was previously unused."  You could get a
>> somewhat similar effect with compound element overloading, but only somewhat
>> similar.
>>
>> Eddie
>>
>
> What's involved in coding up a patch for prototype testing?
>
> I've not looked into the innards of the click parser and intermediate code
> generator.
>
> Thanks.
>
> -Philip
>
>
>
>  The advantage of graft points was that you'd have to plumb instances
>>> individually, same as for input and output ports.
>>>
>>> My only point about graft point was that (a) they would simplify keeping
>>> track
>>> of indices on complex objects (especially for objects that are generated
>>> from
>>> scripts with variable numbers of inputs and outputs); (b) they would
>>> simplify
>>> notation by specifying both input and output to the grafted-to object at
>>> the
>>> same time, and (c) they would impose rules about graft points being used
>>> in
>>> pairs that doesn't exist for inputs and outputs which are orthogonal to
>>> each
>>> other (at least with respect to an object's perspective of the outside
>>> world).
>>>
>>> I thought about it some more, and if the default for any unspecified
>>> (graft)
>>> connection was :: { input -> output } then that would make it very easy
>>> to
>>> "pepper" an object with various inspection and instrumentation points, or
>>> points where you might later want to apply additional processing on a
>>> packet
>>> as it flows through the innards of a class.
>>>
>>> I could easily foresee a complex object where I had graft points for:
>>>
>>> [0] the packet at ingress;
>>> [1] the packet after it has SNATting performed;
>>> [2] the packet after deep inspection into layer 7 and rewriting of
>>> addresses;
>>> [3] resetting the timer on the association;
>>> ...
>>> [n] the packet at egress;
>>>
>>> And you wouldn't need to recode an object to add to peek into it at
>>> various
>>> well-known (and previously defined) places.
>>>
>>> Like I said: graft points are just a notational convenience. At the end
>>> of the
>>> day, they would just map into pairs of input and output ports... but the
>>> implementation would be handled by the preprocessor.
>>>
>>>
>>> On 1/21/11 4:47 PM, Eddie Kohler wrote:
>>>
>>>> Hey, a couple points.
>>>>
>>>> (1) Unlike Cliff and Ian, I see some value for importing external
>>>> elements
>>>> into a compound. Perhaps a statement like "import(ELEMENTNAME)" would be
>>>> required. Although new errors could happen, they'd be pretty easy to
>>>> understand even now, and the messages could be improved.
>>>>
>>>> (2) On the below, we generally write debuggers like this:
>>>>
>>>> // elementclass Debugger {$tag | input -> output};
>>>> elementclass Debugger {$tag | input -> IPPrint($tag, MAXLENGTH 64) ->
>>>> output};
>>>>
>>>> Then you refer to Debugger as an element.
>>>>
>>>> I want to note that graft points as used in THIS mail are supported now;
>>>> they are implemented as normal inputs and outputs. I don't understand
>>>> what
>>>> you gain by treating grafts as separate from normal inputs and outputs.
>>>> They
>>>> must always be connected or there are errors.
>>>>
>>>> Eddie
>>>>
>>>>
>>>> On 01/20/2011 04:11 PM, Philip Prindeville wrote:
>>>>
>>>>> One other nice property about graft-points is this:
>>>>>
>>>>> elementclass MyIncrediblyHairyObject {
>>>>> ...
>>>>> }
>>>>>
>>>>> miho :: MyIncrediblyHairyObject;
>>>>> ...
>>>>>
>>>>> miho [0]<-> null :: { input -> output }<-> [0] miho;
>>>>> // miho [0]<-> dbg0 :: { IPPrint("Inspection 0", MAXLENGTH=64) }<-> [0]
>>>>> miho;
>>>>>
>>>>>
>>>>> and by just moving the comment prefix around, I can turn on or off
>>>>> debugging, without having to disturb the body of the elementclass
>>>>> itself.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 1/20/11 3:59 PM, Philip Prindeville wrote:
>>>>>
>>>>>> I've been thinking about this some more...
>>>>>>
>>>>>> If I have the following:
>>>>>>
>>>>>> elementclass Foo {
>>>>>>
>>>>>> stuff1 -> external-object -> stuff2;
>>>>>>
>>>>>> }
>>>>>>
>>>>>> then this can be rewritten as:
>>>>>>
>>>>>> elementclass Foo {
>>>>>> stuff1 -> [N] output;
>>>>>> input [M] -> stuff2;
>>>>>> }
>>>>>>
>>>>>> f :: Foo;
>>>>>>
>>>>>> f [N] -> external-object -> [M] f;
>>>>>>
>>>>>> I'd like to propose a notational convenience called "graft" (as in a
>>>>>> graft-point).
>>>>>>
>>>>>> graft[0] would be short-hand for 1+ the highest used input, and [0]
>>>>>> graft
>>>>>> would be 1+ the highest used input.
>>>>>>
>>>>>> (and so on for [1], [2], etc.)
>>>>>>
>>>>>> We'd need a new operator for graft-points. Maybe:
>>>>>>
>>>>>> f [G]<-> [a] external-object [b]<-> [G] f;
>>>>>>
>>>>>> it would be a syntactic error to mismatch subscripts for the object
>>>>>> being
>>>>>> grafted to.
>>>>>>
>>>>>> The notation inside the elementclass would be:
>>>>>>
>>>>>> elementclass Foo {
>>>>>> stuff1 -> graft [G] -> stuff2; // or ... [G] graft ...
>>>>>> }
>>>>>>
>>>>>> Does that make sense?
>>>>>>
>>>>>> -Philip
>>>>>>
>>>>>>
>>>>>> On 1/18/11 3:43 PM, Beyers Cronje wrote:
>>>>>>
>>>>>>> The config you posted below Ian explicitly states "This would be
>>>>>>> legal:" at
>>>>>>> the top. I think Ian is referring to the second config that will
>>>>>>> cause
>>>>>>> issues:
>>>>>>>
>>>>>>> "
>>>>>>> I think this should complain that fd[0] is being used twice (port
>>>>>>> connection error), although it may take a minute to see why that's
>>>>>>> the
>>>>>>> case (and would be much trickier to see in a more complex config):
>>>>>>> --------------------------------------
>>>>>>> fd::FromDevice(...);
>>>>>>>
>>>>>>> elementclass Bar {
>>>>>>> fd[0] -> Print() -> [0]output;
>>>>>>> }
>>>>>>>
>>>>>>> a::Bar() -> Discard();
>>>>>>> b::Bar() -> Discard();
>>>>>>> --------------------------------------
>>>>>>> "
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jan 19, 2011 at 12:32 AM, Philip Prindeville<
>>>>>>> philipp_subx at redfish-solutions.com> wrote:
>>>>>>>
>>>>>>>  On 1/18/11 7:34 AM, Ian Rose wrote:
>>>>>>>>
>>>>>>>>> If I am thinking this through correctly, IMHO it wouldn't be a good
>>>>>>>>> idea
>>>>>>>>> to allow elementclasses to do this. Reason being that in some cases
>>>>>>>>> you
>>>>>>>>> could create port connection errors merely through declaring
>>>>>>>>> multiple
>>>>>>>>> elements of your new elementclass type. This would be an unexpected
>>>>>>>>> and
>>>>>>>>> confusing error since its impossible to do currently. AFAIK
>>>>>>>>> currently
>>>>>>>>> there are no errors that can occur merely by *declaring* too many
>>>>>>>>> elements of some type. So this would introduce a whole new category
>>>>>>>>> of
>>>>>>>>> error. Some examples:
>>>>>>>>>
>>>>>>>>> This would be legal:
>>>>>>>>> --------------------------------------
>>>>>>>>> fd::FromDevice(...);
>>>>>>>>>
>>>>>>>>> elementclass Bar {
>>>>>>>>> fd[0] -> Print() -> [0]output;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> a::Bar() -> Discard();
>>>>>>>>> --------------------------------------
>>>>>>>>>
>>>>>>>>> I think this should complain that fd[0] is being used twice (port
>>>>>>>>> connection error), although it may take a minute to see why that's
>>>>>>>>> the
>>>>>>>>> case (and would be much trickier to see in a more complex config):
>>>>>>>>>
>>>>>>>> Sorry, not seeing why the above case represents using the port
>>>>>>>> twice...
>>>>>>>>
>>>>>>>>
>>>>>>>>  --------------------------------------
>>>>>>>>> fd::FromDevice(...);
>>>>>>>>>
>>>>>>>>> elementclass Bar {
>>>>>>>>> fd[0] -> Print() -> [0]output;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> a::Bar() -> Discard();
>>>>>>>>> b::Bar() -> Discard();
>>>>>>>>> --------------------------------------
>>>>>>>>>
>>>>>>>>> In order to cause this same error currently (without the proposed
>>>>>>>>> elementclass enhancement) you'd have to do this, which I think
>>>>>>>>> makes the
>>>>>>>>> error more obvious:
>>>>>>>>> --------------------------------------
>>>>>>>>> fd::FromDevice(...);
>>>>>>>>>
>>>>>>>>> elementclass Bar {
>>>>>>>>> input[0] -> Print() -> [0]output;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> fd[0] -> a::Bar() -> Discard();
>>>>>>>>> fd[0] -> b::Bar() -> Discard();
>>>>>>>>> --------------------------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Just my $0.02.
>>>>>>>>>
>>>>>>>>> - Ian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 01/17/2011 07:55 PM, Philip Prindeville wrote:
>>>>>>>>>
>>>>>>>>>> Yeah, it especially makes sense to have arpfoo be global if it
>>>>>>>>>> needs to
>>>>>>>>>>
>>>>>>>>> be accessible from two different elementclass's, one that deals
>>>>>>>> with the IP
>>>>>>>> flow (input [0] and output [0]) and another one that deals strictly
>>>>>>>> with
>>>>>>>> the
>>>>>>>> ARP request/reply flow (input [1] and output [1]).
>>>>>>>>
>>>>>>>>> Someone else will have to come up with the patches... I've not yet
>>>>>>>>>>
>>>>>>>>> dabbled in the code itself.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 1/17/11 4:35 PM, Eddie Kohler wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Philip,
>>>>>>>>>>>
>>>>>>>>>>> I can see why you thought compound elements would work that way,
>>>>>>>>>>> but
>>>>>>>>>>>
>>>>>>>>>> they don't. They are very strictly encapsulated: all connections
>>>>>>>> to other
>>>>>>>> elements must take place through explicit inputs and outputs.
>>>>>>>>
>>>>>>>>> I admit it would make sense to do it the way you've imagined.
>>>>>>>>>>> Patches
>>>>>>>>>>>
>>>>>>>>>> welcome...
>>>>>>>>
>>>>>>>>> Eddie
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 1/15/11 2:53 PM, Philip Prindeville wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I've got a configuration where I do:
>>>>>>>>>>>>
>>>>>>>>>>>> ...
>>>>>>>>>>>> arpfoo :: ARPQuerier(...);
>>>>>>>>>>>>
>>>>>>>>>>>> elementclass Bar {
>>>>>>>>>>>> ...
>>>>>>>>>>>> class :: classifier(...);
>>>>>>>>>>>> ...
>>>>>>>>>>>> class [2] -> [1] arpfoo;
>>>>>>>>>>>> ...
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> but it complains that "unknown element class 'arpfoo'" in a few
>>>>>>>>>>>>
>>>>>>>>>>> places, and that input 1 isn't used...
>>>>>>>>
>>>>>>>>> So I'm confused. Everything is scoped globally... even stuff
>>>>>>>>>>>> defined
>>>>>>>>>>>>
>>>>>>>>>>> within an elementclass gets scoped globally.
>>>>>>>>
>>>>>>>>> Why then can't I access a global variable from within an
>>>>>>>>>>>>
>>>>>>>>>>> elementclass's scope?
>>>>>>>>
>>>>>>>>> What am I missing?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> -Philip
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>
>