Date: Sat, 8 Feb 2014 19:52:23 -0500 From: Outback Dingo <outbackdingo@gmail.com> To: Juli Mallett <jmallett@freebsd.org> Cc: "freebsd-mips@FreeBSD.org" <freebsd-mips@freebsd.org> Subject: Re: FreeBSD 10.0 image and build script for EdgeRouter Lite Message-ID: <CAKYr3zygzU4pitun3yJXRQTBt75viSYoxoPLX545jgQb47S5OQ@mail.gmail.com> In-Reply-To: <CACVs6=-0V0R_7G%2B0jn9iFbAauNQiYc1iTg0_9LqBANYPEyagbg@mail.gmail.com> References: <20140125210308.GA6936@rtfm.net> <52EE7183.1070806@pix.net> <CADgEyUtSzJaERXS9VMi5QNX-aRLOmh7QeaS-c-PnTkfROmNMMw@mail.gmail.com> <20140205190456.GA15313@plebeian.afflictions.org> <CAKYr3zw3FCBp9K2jTJXpoenwo9O1vs%2BUEmPh_Vc0h7avjScC=Q@mail.gmail.com> <CACVs6=-wcgv9grMXfs==EW9or=qAo=yrvV%2BtEvCGK2=0cg6ddA@mail.gmail.com> <52F64128.7010000@rewt.org.uk> <CACVs6=-0V0R_7G%2B0jn9iFbAauNQiYc1iTg0_9LqBANYPEyagbg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Feb 8, 2014 at 1:39 PM, Juli Mallett <jmallett@freebsd.org> wrote: > On Sat, Feb 8, 2014 at 6:37 AM, Joe Holden <lists@rewt.org.uk> wrote: > > > On 08/02/2014 00:23, Juli Mallett wrote: > >> > >> The most likely scenario is that very minor changes will be required to > >> support the additional model, possibly as little as just recognizing its > >> model identifier. > >> > >> Juli.... > >> > > > > IIRC the bigger variants are Octeon II with hardware switches (likely > > marvell/broadcom) - what are the chances of getting support for either > > given the NDA requirements? > okay so wait, should i buy the light and not risk getting the pro and npot having it worlk? Id really like the pro version > > > Well, Octeon II is already kind-of supported; some ancillary hardware may > need new drivers written, and depending on the specific device we may or > may not have Ethernet support already. > > NDA is not even remotely required to add support for any of that. In my > experience, I'd say it takes someone being funded to make that kind of work > happen, though. If anyone on the list wants to fund that kind of work, I > can point them in the direction of several people who could do it. It > happening on a volunteer basis (even if provided with hardware) is a bit > less of a given, unfortunately. At least, that's my most honest appraisal > at the moment. > > I was working with an engineer at Cavium to support all of the Octeon II > hardware, but unfortunately haven't heard back from him in some time, after > asking for the code to be reworked. > > Still, it's much easier to support a device from a company that already > heeds their GPL obligations, and so one can see in their Linux sources > very, very easily whatever the nature of their own funky quirks and > modifications may be. Unlike companies like Radisys who flagrantly violate > the GPL because they consider anything they do on things like packet > processors to be a trade secret, or who think that their GPL obligations > don't apply to people who buy second-hand hardware. Ubiquiti is much, much > better on that front. > > As to hardware switches, the question gets trickier, because support for > them is not a binary yes/no. And, for added irony, even big companies > often have to settle for support for them being in the form of a binary > blob. We could probably do basic configuration, but hopefully it's not > required. Some things like switches (though I've never seen this be the > case with a hardware switch, more things like link aggregators) require a > huge amount of work just to put them into a default state where they do > nothing. > > Support for mucking about with weird configuration may just never happen. > More basic configuration, well, that's a different story. Sometimes it > requires an NDA. Often one can find support for the same or similar > hardware online, though, and if one has a very controlled environment and a > lot of patience it may even be possible to do some very oldschool reverse > engineering (that is, send in a packet, look at a bunch of places in memory > to see what changes, repeat; or use a JTAG to watch crucial moments when > the switch is being configured.) If you can find code in some obscure > project that does it, it's not that hard to add the basics to FreeBSD. If > that kind of work happens on a volunteer basis I'd be shocked, because (1) > it sucks (2) it involves a lot of disappointment (3) FreeBSD still doesn't > even come close to having configuration *concepts* like things like > switches have and like people who configure switches are used to (4) the > only pressing reason to really want to is because of business reasons, and > not getting paid for that kind of work can be tough, and also it's not > always clear what the motivation would be[1]. > > Thanks, > Juli. > > 1: (Of course, people can surprise you; I wrote the first open source WAN > Optimization package because I was broke and had an awful network card and > figured deduplication would help, and eventually kept working on it because > I felt that it was a really basic kind of network infrastructure that ought > to be available to everyone, even people who can't afford the high cost of > making their networks in remote areas more efficient. But of course, then > it's tough because everyone using it is doing so for their own urgent > business purposes, and sometimes they find they need the kind of support a > commercial organization would provide, and it can be very frustrating for > them that there isn't a team of people waiting to solve all their problems. > I know some people avoid work that's going to get that kind of user, and I > can see work supporting hardware switches falling into that category.) > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAKYr3zygzU4pitun3yJXRQTBt75viSYoxoPLX545jgQb47S5OQ>