Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 8 Feb 2014 10:39:45 -0800
From:      Juli Mallett <jmallett@FreeBSD.org>
To:        Joe Holden <lists@rewt.org.uk>
Cc:        "freebsd-mips@FreeBSD.org" <freebsd-mips@freebsd.org>
Subject:   Re: FreeBSD 10.0 image and build script for EdgeRouter Lite
Message-ID:  <CACVs6=-0V0R_7G%2B0jn9iFbAauNQiYc1iTg0_9LqBANYPEyagbg@mail.gmail.com>
In-Reply-To: <52F64128.7010000@rewt.org.uk>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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?


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.)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACVs6=-0V0R_7G%2B0jn9iFbAauNQiYc1iTg0_9LqBANYPEyagbg>