Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Jan 2012 10:54:21 -0800
From:      Xin Li <delphij@delphij.net>
To:        Robert Millan <rmh@freebsd.org>
Cc:        Kostik Belousov <kostikbel@gmail.com>, Adrian Chadd <adrian@freebsd.org>, d@delphij.net, freebsd-arch@freebsd.org
Subject:   Re: RFC: MK_BLOBS build option
Message-ID:  <4F204FDD.60807@delphij.net>
In-Reply-To: <CAOfDtXME9PzmC2S8uqfYoPLb0%2BbbFKsBY5H3EWK3fpkGp7J8Ow@mail.gmail.com>
References:  <20120122201814.GA32081@thorin> <4F1DBB94.900@delphij.net> <CAOfDtXME9PzmC2S8uqfYoPLb0%2BbbFKsBY5H3EWK3fpkGp7J8Ow@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Robert,

On 01/23/12 14:17, Robert Millan wrote:
> 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.  Maybe 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.

I meant this, basically we have:

GENERIC -- default kernel in FreeBSD
SOURCELESS_EXCLUDES -- a meta-'overlay' that contains 'include
SOURCELESS_HOST_EXCLUDES' and 'include SOURCELESS_UCODE_EXCLUDES'
SOURCELESS_HOST_EXCLUDES -- a 'overlay' that contains a few 'nodevice
<devname>'s
SOURCELESS_UCODE_EXCLUDES -- ditto

This way, e.g. GENERIC-DEBIAN would be simply:

include GENERIC
include SOURCELESS_EXCLUDES

This way would minimize the maintenance of the GENERIC-DEBIAN I think
while not compromising your policy of not including these stuff in binary?

Cheers,
- -- 
Xin LI <delphij@delphij.net>	https://www.delphij.net/
FreeBSD - The Power to Serve!		Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8gT90ACgkQOfuToMruuMCFkwCfZbRP6g0v7eq14t02bWX2d+sf
oWYAnRMwr6XDcZmyiYWMJmEA5gtxQSsh
=ONW1
-----END PGP SIGNATURE-----



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F204FDD.60807>