12 Aug
2014
12 Aug
'14
9:48 a.m.
In line.
On 12/08/14 03:33, Gui Iribarren wrote:
--
./p4u
On 11/08/14 20:49, Gioacchino Mazzurco wrote:
In my opinion it would be better to have a single packages
(lime-hardware-modules) with a set of options which can be enabled or
disabled. Same approach busybox follows (and many others). So from
menuconfig you have a single configurable packet where can select the
hardwares you want to include.
I have just pushed latest commits from Frank
sandbox bringing the new hardware
detection feature to our main repository
https://github.com/libre-mesh/lime-packages/commit/4c3835541b4823cbb0936791…
Here you can find also some fresh compiled images, together with Frank we
tested on tl-wdr3500 today and on tl-wdr3600 yesterday with positive results
http://madrid.guifi.net/~gioacchino/openwrt/lime/bin/ar71xx/
The good things is that hardware detection module will take care of hardware
quirks while protos can be more hardware agnostic :)
I'm not entirely happy with having a package called "lime-hwd-eth1-wan"
and i'm even more puzzled with "lime-hwd-tl-wdr3600" - are we going to
have such packages for many other boards out there?
it might be just me, but at first sight i get the feeling we're heading
in the wrong direction i got wan to work on wdr3600 and wdr3500 as well,
without this module,
so i'm not entirely sure the problem you're trying to attack
I've not read the code you talking about, but I would say we should
avoid putting specific-hardware code in the common/generic code.
Something like "if wdr3600" then "blah", is quite dirty.
In addition, if you are modifying the general behavior then it is very
likely that you broke the compatibility with some other hardware.
I think the Gio/Frank approach is quite good.
i'm not saying the hardware-detection module is a
bad idea; instead, i
think it makes a lot of sense, but not in these particular solutions :)
that can be addressed in a more "upstream" way
for what is worth, congratulations on running this succesfully on
wdr3x00! if it proves useful right now, i guess we might merge it even
if it's not the ideal solution, and try to refactor the code in the future
in any case, i think this branch deserves some mumble meeting :D
I agree with you here.
Cheers!
P.S. feedback is welcomed
aside from everything, i think it would be very valuable for you to sit
down with Frank and guide him to use "git rebase -i" to squash commits
into more useful blobs
(i.e. unlike 8d14665915 "sintax fix" for example :P )
probably rebasing the whole branch on top of 23289691 as well
avoiding those "Merge branch 'develop'..." which won't make much
sense
when the branch is accepted in develop. cheers and keep up the good work!
gui
Cheers ;)
_______________________________________________
Dev mailing list
Dev(a)lists.libre-mesh.org
https://lists.libre-mesh.org/mailman/listinfo/dev
_______________________________________________
Dev mailing list
Dev(a)lists.libre-mesh.org
https://lists.libre-mesh.org/mailman/listinfo/dev