From owner-freebsd-mips@FreeBSD.ORG Sat Feb 8 18:40:14 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 2BA0DA28 for ; Sat, 8 Feb 2014 18:40:14 +0000 (UTC) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 921FC1468 for ; Sat, 8 Feb 2014 18:40:13 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id c6so3704249lan.11 for ; Sat, 08 Feb 2014 10:40:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=2jY97uIHbrWMTIbndUbHXdKwAUBdU2xry3stz2QFuXc=; b=DnQCKasoTFoezuEK3RB400Ndt+njo/lgzlNZA2Nevr/jJOe7XZ60idJLzUTjaaAucm r092w4wplXr2KsN70y3JC2zvRP6IwVi3Xdk1NRChIz6NozIpDBpZcJ/FWNx9Yk9Meuqc VF7ZNpz8wTkf4raYMeftwz5Z+Brmg76njxDwY3ralSr4NtyjBMfL1e4Z3VHPzWOVlCSq qoHvzSPw9rWaZbUj2YHGffEhBu5D4j9KjlVUyg8oUvqRo708gnp2b0u6IUtf+Z0l0ljy R42zZcojKAGAbD9PfaNGa/sdsSQ9TXOB+q7p/xFF8iGL9ykCM1XaJt84xmtRa+CnI+10 UcmA== X-Gm-Message-State: ALoCoQn8cpzC+eEA8JeXEOqLvTIA40eFszg8Ne77uw94GHMb41heNDAgbcvVFtLCqgZ7H6+FBQl9 X-Received: by 10.112.132.102 with SMTP id ot6mr14080255lbb.27.1391884805968; Sat, 08 Feb 2014 10:40:05 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.152.130.72 with HTTP; Sat, 8 Feb 2014 10:39:45 -0800 (PST) In-Reply-To: <52F64128.7010000@rewt.org.uk> References: <20140125210308.GA6936@rtfm.net> <52EE7183.1070806@pix.net> <20140205190456.GA15313@plebeian.afflictions.org> <52F64128.7010000@rewt.org.uk> From: Juli Mallett Date: Sat, 8 Feb 2014 10:39:45 -0800 X-Google-Sender-Auth: 3QhuwbebcxfFQlsE7qEz7Q0uQe8 Message-ID: Subject: Re: FreeBSD 10.0 image and build script for EdgeRouter Lite To: Joe Holden Content-Type: text/plain; charset=UTF-8 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: Sat, 08 Feb 2014 18:40:14 -0000 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? 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.)