From owner-freebsd-arch@FreeBSD.ORG Fri Aug 19 22:57:49 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0742106564A; Fri, 19 Aug 2011 22:57:49 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C9DA78FC17; Fri, 19 Aug 2011 22:57:49 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 654AD46B2A; Fri, 19 Aug 2011 18:57:49 -0400 (EDT) Date: Fri, 19 Aug 2011 23:57:49 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Gary Palmer In-Reply-To: <20110819203114.GF88904@in-addr.com> Message-ID: References: <810527321.20110819123700@serebryakov.spb.ru> <201108191401.23083.pieter@degoeje.nl> <425884435.20110819175307@serebryakov.spb.ru> <20110819172252.GE88904@in-addr.com> <20110819203114.GF88904@in-addr.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Pieter de Goeje , Lev Serebryakov , freebsd-arch@freebsd.org Subject: Re: FreeBSD problems and preliminary ways to solve X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 22:57:50 -0000 On Fri, 19 Aug 2011, Gary Palmer wrote: >> For server/appliance-centric devices, we're going quite well. For consumer >> devices, less so. However, it's generally the case that things have >> dramatically improved in the last ten years: companies come to us with >> drivers now, asking how to get them merged, and frequently their developers >> get commit bits and maintain them in-tree even. Compare this to 2000 when >> we had hacked up Intel device drivers, and other than Adaptec, almost no >> storage vendors closely involved in the project. > > While on the most part I agree with the fact that a fair number of server > chips and chipsets are supported I think we are still missing key components > for truly reliable and scalable systems, including SAN multipath support > (yes, we have primitive support but it doesn't know about limitations of > different systems, e.g. HP EVA 5000s which do a LUN failover if you query > the LUN down the wrong path. Yes, the EVA 5000 is an EOL system but its an > example of the issues a proper multipath solution should solve. I mean no > offense to the authors of the current code either). IPMI boards/interfaces > seems to be a constant problem and I'm not entirely sure we have a good > handle on SERDES support for NICs in blade systems. > > Does the project or the foundation make any effort to directly engage with > manufacturers to ensure we have robust support for their products? Those specific devices are well outside my area of expertise, so I'll have to leave those to others to address. Let me turn it around, however: have you approached the Foundation to bring weak support there to the board's attention? As far as I'm aware, no one has ever mentioned this to board@ before, and it's something the board would surely work on actively if we realised it was a problem. More generally, yes, we do chat with hardware vendors regularly, and have attempted to organise a number of meetings on behalf of the FreeBSD Project when we're aware of gaps. We also try to help vendors figure out how to get their drivers back into FreeBSD. However, we can only be effective advocates for the project when we're aware of gaps, and we rely on FreeBSD developers and consumers to help us figure out what they are. (We also try to meet with companies that use FreeBSD in their products to help them figure out how to interact with the project better -- so if you're aware of such companies, perhaps one that needs help working out what to do about support for the storage systems you have in mind, do drop us an e-mail!) Robert