From owner-freebsd-mips@FreeBSD.ORG Sun Feb 9 00:52:24 2014 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E52D55D1; Sun, 9 Feb 2014 00:52:24 +0000 (UTC) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 95B941FDA; Sun, 9 Feb 2014 00:52:24 +0000 (UTC) Received: by mail-oa0-f45.google.com with SMTP id i11so5980990oag.4 for ; Sat, 08 Feb 2014 16:52:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zxfu4PENuvO45bY0FFuNARAoVP17/T3toEkCfyYyUlA=; b=kO8ioAKVgwtsbaJBnZvxItz2mLAAkdRvZlW4lZJ7TJHznEgG0goRKfaAmRMPX8BYR+ Fst42ndxtOeAaT12di2OImej5ls9Jdbr701JKm0AIMnvG+bychQzC1VpRyvZGRgKzL+k dDcuuYc3Jki43KTNBRK0FkkTUGt9LfQpSm0uwjqC6c4l5O7Vx6J9JdDxa1Jgf8hhIh2G S+L3qrdxj0MpGf9cXV2i9WnwMT70NA8o/FF7w+hViwYbn+6fqJBWIpHaqHFYdWLKN30N 179G4c0Pk6H/zZVN24LH/KsXwKJFiFve/cpLHYUzroH7bcCdYgCizNY6/0pxcxFiTzfT PWhg== MIME-Version: 1.0 X-Received: by 10.182.250.163 with SMTP id zd3mr20497851obc.20.1391907143844; Sat, 08 Feb 2014 16:52:23 -0800 (PST) Received: by 10.76.3.11 with HTTP; Sat, 8 Feb 2014 16:52:23 -0800 (PST) In-Reply-To: References: <20140125210308.GA6936@rtfm.net> <52EE7183.1070806@pix.net> <20140205190456.GA15313@plebeian.afflictions.org> <52F64128.7010000@rewt.org.uk> Date: Sat, 8 Feb 2014 19:52:23 -0500 Message-ID: Subject: Re: FreeBSD 10.0 image and build script for EdgeRouter Lite From: Outback Dingo To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-mips@FreeBSD.org" X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 00:52:25 -0000 On Sat, Feb 8, 2014 at 1:39 PM, Juli Mallett wrote: > On Sat, Feb 8, 2014 at 6:37 AM, Joe Holden 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" >