i think the current default of displaying routes based on the order they've been added is pretty well ingrained in expectations of people using this tool
adding options to sort the results sounds reasonable. i guess --sort-metric is what you're looking for ? any use in sorting/grouping based on flags or iface or something else ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've since worked on many other projects and have completely forgotten the context of why I filed this. Probably to be able to quickly see which route would trigger for a certain destination.
So if you still want to work on it, then I'd suggest to be able to get the list such that I could do the above. That would probably entail sorting on metric but also accounting for the order in which the kernel would evaluate the routes with the same metric.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i only just found out/remembered we had a bug tracker ;)
that's a good point ... maybe a more general way of looking at it is to provide a sort-by-keys, and the user can select the keys they care about. the default (and fallback if all other keys compare the same) will be "kernel" (as in, the order it returned them), but people can pick other fields (like metric) to sort on instead.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hm, I am not sure if we need many sort options, however sorting by metric/prefixlength to find the most applicable route seems to be an good additional criteria.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i don't feel strongly either way. i figured we'd build an array of pointers and run qsort on it either way, and having the callback to qsort parse arbitrary keys didn't seem too much more work on top of it. but omitting that and hardcoding metric (at least to start with) is also pretty easy. and we can always add later if people really want more.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i think the current default of displaying routes based on the order they've been added is pretty well ingrained in expectations of people using this tool
adding options to sort the results sounds reasonable. i guess --sort-metric is what you're looking for ? any use in sorting/grouping based on flags or iface or something else ?
Wow, took a long time but you've seen it ;-)
I've since worked on many other projects and have completely forgotten the context of why I filed this. Probably to be able to quickly see which route would trigger for a certain destination.
So if you still want to work on it, then I'd suggest to be able to get the list such that I could do the above. That would probably entail sorting on metric but also accounting for the order in which the kernel would evaluate the routes with the same metric.
i only just found out/remembered we had a bug tracker ;)
that's a good point ... maybe a more general way of looking at it is to provide a sort-by-keys, and the user can select the keys they care about. the default (and fallback if all other keys compare the same) will be "kernel" (as in, the order it returned them), but people can pick other fields (like metric) to sort on instead.
hm, I am not sure if we need many sort options, however sorting by metric/prefixlength to find the most applicable route seems to be an good additional criteria.
i don't feel strongly either way. i figured we'd build an array of pointers and run qsort on it either way, and having the callback to qsort parse arbitrary keys didn't seem too much more work on top of it. but omitting that and hardcoding metric (at least to start with) is also pretty easy. and we can always add later if people really want more.