Sowmini.Varadhan at Sun.COM wrote: > On (04/01/09 18:44), Girish Moodalbail wrote: >> /net/trigati.east/export/build/gm209912/possible_mtu >> > > - suggest MAC_PROP_MTU_RANGE instead of MAC_PROP_SUPPORTED_MTU_RANGE
Sure. > > - libdladm: suggest renaming i_dladm_uint32_range_get to i_dladm_mtu_range_get > since this function is very specific to mtu. Idea is to make *i_dladm_uint32_range_get* function a common function for various properties which would need *range* values in the future. I will use a 'switch' statement inside the function and have a case for MAC_*MTU_RANGE. > > - what value would be printed for other drivers like afe, mxfe etc? > I believe these would return ENOTSUP- so would you print "--"? that does > not sound correct- it is intuitively misleading to print a non-zero > value in "current" but print "--" in POSSIBLE. The way I have coded now, it would print "--". I will change it to print the *Current* value. > in conjunction with CR 6787179, the mac layer can itself return both > the min and max for the drivers that do not have a writable-mtu, by > extracting the information in the registered max_sdu. In this case we will have to determine the permission of MTU property and then based on that decide whether you have to go to driver or pick it up from the mac_impl_t. I would say just have one common interface and keep things simple. Just go to driver and get the range. If the driver does not supprot MAC_*_MTU_RANGE, print the *current* value for such drivers. thanks for you comments ~Girish
