[email protected] 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
_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
