From owner-freebsd-arch@FreeBSD.ORG Mon Jan 23 22:17:29 2012 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 4F91D106566B; Mon, 23 Jan 2012 22:17:29 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0EF8F8FC17; Mon, 23 Jan 2012 22:17:28 +0000 (UTC) Received: by iagz16 with SMTP id z16so7965610iag.13 for ; Mon, 23 Jan 2012 14:17:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bcIn4oGhvVMNu4BJDUal8FNGJjVikFGmep9l4I6nB+M=; b=fk1+1x6Soi92d1oLTkLp3DjDKMYc/CCiGxoPmGnl9l/jxZOoCefpry5EOqpKu92dKK LXrzdX2ufSF2yhUgvwy8Zlth7gLsx2C+4doVOIR8YUGuIXaRhqPXMKmCk0NInp/R0/vf bbANhxuvpCjP80FPihObBhq1qYHF7sWkcNf0k= MIME-Version: 1.0 Received: by 10.42.131.136 with SMTP id z8mr9725131ics.5.1327357048440; Mon, 23 Jan 2012 14:17:28 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.42.152.10 with HTTP; Mon, 23 Jan 2012 14:17:28 -0800 (PST) In-Reply-To: <4F1DBB94.900@delphij.net> References: <20120122201814.GA32081@thorin> <4F1DBB94.900@delphij.net> Date: Mon, 23 Jan 2012 22:17:28 +0000 X-Google-Sender-Auth: o1FU0hk3FFVmHyckvBMX8kWOL6k Message-ID: From: Robert Millan To: d@delphij.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , Adrian Chadd , freebsd-arch@freebsd.org Subject: Re: RFC: MK_BLOBS build option 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: Mon, 23 Jan 2012 22:17:29 -0000 El 23 de gener de 2012 19:57, Xin Li ha escrit: > Please note that it's still possible to compile these into kernel if > they present in the kernel compile configuration (for instance, device > hptmv), which sounds a little bit non-intuitive to me. =C2=A0Maybe we > should create three include file (BLOBS, BLOBS_HOST, BLOBS_UCODE > perhaps) that lists these modules as 'nodevice ' in the > same time, so they can be included from a kernel configuration file at > the end? Sounds useful, but I'm not sure how would one implement this so that it is maintainable and doesn't break. First when you create a file to disable ucode-blobs, you have to enumerate the drivers again, creating redundancy (which usually leads to bitrot). Then when you create a file that disables both ucode-blobs and host-blobs, you either enumerate the drivers over again, adding a second level of redundancy, or have to use "include" directive. But you can't just include both ucode-blob and host-blob files because they both include GENERIC, and then GENERIC would be included twice, right? The idea sounds great (in my case it'd allow me to reduce our delta a bit further), but in practice I'm not sure this can work.