On 2/4/19 3:50 PM, Grant Taylor wrote: > On 02/03/2019 11:23 AM, Michael Orlitzky wrote: >> Ultimately netifrc is just a shell script that parses another shell >> script to construct a third shell script. I don't think doing it with >> only two shell scripts is that much less elegant =) > > The elegance, or lack there of, is not in the number of shell scripts. > Rather the fact that tc (QoS) parameters are stuffed into a command line > verses having things split out and parsed is what I dislike. Take VLANs > for example, there is a netifrc parameter for specifying the VLAN IDs > that belong on an interface. Netifrc will then construct the commands. > People don't need to know how to construct the commands themselves to > utilize VLANs. tc (QoS) is not anywhere nearly as nice. >
If you're willing to go all-out to do this right, you can implement that parsing yourself. You can create a package called netifrc-qos that consists of (only?) two files: an OpenRC service script, and an associated conf.d file. Inside the conf.d file you can use whatever variables you like, and then have the init script parse them and run the resulting commands. Afterwards you'd create an ebuild for it, install it from an overlay, and then edit the conf.d file accordingly. It's a lot of work, but that's the most Gentoo way to do it IMO. You might also want to check with the OpenRC/netifrc projects to see if they have anything like this in the works already. Either way they may be willing to collaborate on a design.
