FreeBSD 10.0 image and build script for EdgeRouter Lite

[Outback Dingo]

On Sat, Feb 8, 2014 at 1:39 PM, Juli Mallett <jmallett at freebsd.org> wrote:

> On Sat, Feb 8, 2014 at 6:37 AM, Joe Holden <lists at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-mips
> To unsubscribe, send any mail to "freebsd-mips-unsubscribe at freebsd.org"
>