On (08/31/09 10:48), Sebastien Roy wrote: > Yes, the driver has to know which flags are set so that it can do its > job, but it shouldn't have to do sanity checking on the pr_flags value > to make sure that bobus flags aren't set. Thinking about this a bit
I agree that the bogus flag checking can be done in the gld layer > 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. --Sowmini
