> > more, though, is the current implementation the way it is because it > > makes it easier to add new flags? > > The original idea (when doing MAC_PROP_DEFAULT) was to allow the > additon of new flags. But, some feeping creaturism may have happened- > on revisiting the code, the MAC_PROP_POSSIBLE seems a bit confusing. > it's only handled for MTU, and the each driver has "if !(pr_flags & > MAC_PROP_POSSIBLE) return ENOTSUP" which makes one wonder why the > driver would ever return ENOTSUP for a getprop of the mtu (and only > return success for the range). Turns out that the code works because > getprop(MAC_PROP_MTU) is handled in gldv3, but I'm not sure how this > would work for a case where gld has to contact the driver to get both > current and possible values for some property. So some tightening of > interfaces would be a Good Thing, I think.
Indeed. I was surprised by the amount of boilerplate code the iptun driver needed to correctly use the m_getprop interface. We need to strive to keep the driver code concerned only doing things that cannot be done by the framework -- e.g., the framework should be able take care of validating pr_valsize. -- meem _______________________________________________ networking-discuss mailing list [email protected]
