On 17/11/15 10:12, Dave Taht wrote:
> we can break anything until it goes upstream. I'm not satisified with
> the api (or wasn't 2 months back)....

Could you elucidate on what is wrong with the API?  My understanding of
the present code is that additional options can be transferred between
kernel space & user space (tc) with 'ease' via the netlink API.  Indeed
the 'squash' enable/disable option is passed as a new option via this
API.  Also look at how easy the recently implented rtt, target & memory
options were to introduce without backward/forward compatibility issues.

Where it falls down is where one passed option is used to control more
than one thing - that's not an API thing really, it's how we use the
API. For example and in my opinion, squash should not have been passed
as a 'diffserv mode' as this limits how combinations of diffserv mode &
squash may be implemented.  That's precisely why I took the step to
split out the diffserv mode and squash mode (like for example 'atm'
compensation or not)  Because 'squash' was previously regarded as a
diffserv mode it does cause a compatibility issue (it won't blow up, but
it may not go into quite the mode expected, or the reporting of mode via
tc may not quite match'

Personally, i'd say break it now while we can and get what I consider a
better implementation out there.  I'm not the only person out here, on
this list, I may be wrong.