On Fri, 2016-12-30 at 16:09 +0100, Bjørn Mork wrote: > Fix it instead :) I have submitted patches for kernel the network stack to improve QoS for ADSL (ie where ATM cells are the link layer carrier). I'm not terribly forgiving of the long drawn out initiation rites the kernel dev's seem to demand, so I eventually gave up. (It didn't help that the kernel networking dev's all seemed to use cable and so didn't notice the issue. As I was a heavy ADSL user it was a very pertinent itch for me.) My co-conspirator, Jesper Brouer, did persevere in the area and is now a name some in kernel development might recognise. Years later he re-submitted the patch. When it was rejected by the same people in much the same way he responded "please lets not go through this again", and it was accepted. > FWIW, I find it much harder to document a new feature than > implementing it. And I believe many others feel the same. Any help > improving the docs is greatly appreciated. As it happens I did write documentation. Not stuff most people consume directly, but in a effort to use QoS I pored through the kernel source, documented what it did and put the result up in a public place. That documentation is now referenced in a number of places. For example it's in the "SEE ALSO" of the tc-u32 man page, I think because it copied large chunks of it. > New networking features often have a narrow target and are added by a > person knowing the specific area pretty well, but not necessarily > everything else... Writing good docs in this context is difficult > because your point of view is so different from the readers. I acknowledge it's hard to write good documentation. But I wasn't talking about language skills. I was talking about writing a single word. There wasn't one for tc for a long while. Some modules of tc are still only mentioned in examples - like the ifb device (which sadly because it's a key part of the traffic control puzzle). Some get an introductory para only: atm - a scheduler for ATM VC's. gact - probabilistic filter action. gred - generalised random early detection scheduler. hhf - Heavy-Hitter Filter scheduler. multiq - driver for multi queue devices, disguised as a scheduler rsvp - Match Resource Reservation Protocol filter. qfq - better version of pfifo, maybe. At least a casual user can find the above and look up the kernel source if they are desperate enough (I did it after all). But there are other parts still haven't attracted a single word: blackhole - a scheduler that always drops packets. canid - a filter that looks at CAN bus ID's. mq - the default scheduler used for virtual devices. plug - scheduler allowing user space start / stopping of flows. teql - link bonder disguised as a scheduler. text - filter matching strings of text in a packet. > Note that the reason there are two sets of tools is exactly because > they *didn't* turn the existing tools into something > unrecognisable. The existing tools were left alone when the kernel > API went from ioctls to netlink. You learn something new every day. I had read the kernel devs had rewritten net-tools. I presumed that was because the ioctl interface had gone, so they were doing it out of the kindness of their hearts to reduce the impact of the change over. Now I've looked at the source I see that isn't so. > But I see no point in the subject of this discussion. It always puzzles me when I see someone make a point like this - right after adding another 100 words to the very discussion they say is pointless! > Leave net-tools as they are for anyone used to them. There are 2(!) versions of ifconfig available - one in inettools and one in net-tools. I don't recall anybody suggesting we remove either. The issue is the new maintainer of net-tools is changing it's output. This could reasonably be expected to break scripts scraping it. Since its been superseded the suggestion is packages using it switch to iproute2 rather than simply adapting to the change. Re-wording that in Debian terms: that means no packages should depend on it. Granted this simple suggestion has prompted several people to charge off on vaguely related hobby horses, and I'm a prime if not the major offender. Undoubtedly this has distracted from the original discussion. That is unfortunate as the original idea seemed sound to me - and not at all pointless.
Attachment:
signature.asc
Description: This is a digitally signed message part