I think that the only problem here is to split lime-system (from lime-system to lime-system + lime-mode-ap + lime-mode-adhoc + lime-mode-ieee80211s) without triggering new bugs.I agree that this is a way better approach: to make new profiles rather than using targets.Also a profile with no access point interface would be useful.
What do you think about this risk?
Just moving the /usr/lib/lua/lime/mode/* files to new packages could be enough?
Is it safe to do?
If it is, should we work for including it in the coming release?
Ciao!
Ilario
2016-07-21 17:53 GMT+02:00 p4u <pau@dabax.net>:
I would not use lime-build directly for this. Instead I would create packages with different set of targets, for instance lime-full-11s or lime-full-adhoc. Then lime-build can have a Profile which selects the corresponding package.
On 21/07/16 16:45, Ilario wrote:
2016-07-13 15:39 GMT+02:00 p4u <pau@dabax.net>:
Good point is that now we have many more targets (routers) available.
I've even tested different architectures such as x86 (which works fine)
and RAMIPS (which does not work fine in Ad-Hoc but it does in 802.11s mode).
So, from my understanding there are architectures where trying to set both ad-hoc and ap modes is not going to work, or it would be better to set 802.11s and ap instead (as Pau told for ramips), right?
In my opinion (ap + ad-hoc | just ap | ap + 802.11s) selection could be made by lime-build depending of the selected target architecture.
lime-build could do this setting different lime-defaults depending on the target (not implemented yet).
Otherwise I suspect that we should move some files [1] from lime-system to new packages lime-mode-adhoc and lime-mode-ieee80211s (and stop using lime-full), then specifying the wanted packages in the targets files [2].
Byyye,
Ilario
[1] at least these
_______________________________________________ Dev mailing list Dev@lists.libre-mesh.org https://lists.libre-mesh.org/mailman/listinfo/dev