Paul Durrant wrote: > On 4/26/07, Sebastien Roy <Sebastien.Roy at sun.com> wrote: >> >> Right. What is a "link" today in dls is really dls's handle on the >> underlying mac, and what is a "vlan" today is really the data-link. >> It's all very confusing, but that was the point of my original mesage. >> :-) >> > > It used to be all quite straightforward... > > mac_ functions were used to access an underlying device drivers mac > functions > dls_ink_ functions abstracted this for the rest of DLS's consumption > dls_vlan_ functions acted on traffic flows separated by VLAN tag (and > a non-VLAN interface was represented as a VLAN with tag 0) > dls_client_ functions acted on traffic flows further sparated by DLSAP > > When the configurable VLAN support was ripped out of DLS (and some of > the other stuff that was done late in the project) the model was > broken. It's therefore probably best if the internals of DLS are > reviewed and the functions and data structures renamed to reflect > their purpose. If VLANs are no longer handled inside DLS then the > dls_vlan_ layer should probably go away and the dls_client_ functions > should talk directly to the dls_link_ functions.
I agree. That would indeed be a good thing to do, and my understanding based on Kais' input is that Crossbow is going to handle that re-organization within dls when VLAN support is moved out of dls and into the vnic. -Seb
