On Sun, Oct 10, 2010 at 02:53:51PM +0200, Marek Lindner wrote:
On Sunday 10 October 2010 06:30:00 Linus Lüssing wrote:
Depending on the scenario, people might want to adjust the number of (re)broadcast of data packets - usually higher values in sparse or lower values in dense networks.
Is there a good reason to change this value at runtime or would a define be enough ? I just get scared when we add too many options that almost nobody cares about.
Well, as said before, in some cases the default value of 3 might be too much, in other cases too less, depending on the topology. However, you might know the kind of topology you have in advance and would like to tweak that without having to know how to for example rebuild a complete image and reflashing it on all devices. You might want to test different values for your topology for tweaking, without having to reflash / reload the kernel module on all devices.
I also don't think too many configuration options in sysfs are that much of a problem. There are also a dozen options for tweaking IP in /proc/sys/net which nearly no one uses. But if someone might need it, (s)he'll be very pleased to not having to recompile and restart the whole kernel for that (or a kernel module in our case).
The average user who might be scared of too many configuration options will be using batctl anyway, won't (s)he? So I'd rather plead to add tweaking options to the sysfs, but omitting them in batctl. Or what do you think?
In other words: What is the use case ? Can we handle it by some kind of auto- detection ?
Sure we could, but then we'd need some more information about the neighbourhood, i.e. with something like a seperate neighbor discovery protocol giving 2-hop-neighbourhood information. Otherwise a node would probably usually send the maximum amount of rebroadcasts as there might be a node in the far distance with a very low tq-value. But that'd require much more effort to implement then these couple of lines :).
Thanks for reviewing
Cheers, Linus
Regards, Marek