Date: Mon, 23 Jan 2012 22:17:28 +0000 From: Robert Millan <rmh@freebsd.org> To: d@delphij.net Cc: Kostik Belousov <kostikbel@gmail.com>, Adrian Chadd <adrian@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: RFC: MK_BLOBS build option Message-ID: <CAOfDtXME9PzmC2S8uqfYoPLb0%2BbbFKsBY5H3EWK3fpkGp7J8Ow@mail.gmail.com> In-Reply-To: <4F1DBB94.900@delphij.net> References: <20120122201814.GA32081@thorin> <4F1DBB94.900@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
El 23 de gener de 2012 19:57, Xin Li <delphij@delphij.net> 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 <device name>' 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOfDtXME9PzmC2S8uqfYoPLb0%2BbbFKsBY5H3EWK3fpkGp7J8Ow>