Date: Fri, 25 Feb 2005 20:39:17 +1100 From: Peter Jeremy <PeterJeremy@optushome.com.au> To: Scott Long <scottl@samsco.org> Cc: hackers@freebsd.org Subject: Re: Driver Update Disk discussion Message-ID: <20050225093917.GA90508@cirb503493.alcatel.com.au> In-Reply-To: <421E7867.9060101@samsco.org> References: <421E7867.9060101@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2005-Feb-24 17:59:19 -0700, Scott Long wrote: >- kernel option support. How do we support vendor modules in a kernel >that might be compiled with PAE (rather common these days), SMP, MAC, >etc. The loader and /boot infrastructure has no concept of this. It's >highly important, though. AFAIK, PAE is only relevant on iA32. I second the suggestion that PAE be treated as a distinct architecture for these purposes. INVARIANTS and WITNESS are the other options that impact ABI. These are probably unnecessary on -RELEASE but it would be nice if people could build a kernel with WITNESS and not have it panic if they loaded a module that wasn't compiled with WITNESS (which I think it the current behaviour). >- kernel api/abi. We are trying to keep the kernel api/abi stable now, ... >don't have the right hash. Should we follow with something similar, or >should we have runtime checks that check symbol/structure signatures? It would be wonderful if we could have a mechanism that did load-time validation that the module was compatible with the kernel. Unfortunately, I don't think there's any sane way to verify data structure compatability. (Verifying function call APIs is reasonably easy). Run-time checking adds overheads which may be significant for commonly used interfaces. >Or should we say that we make no guarantees about a binary-only module >working on anything but a -RELEASE kernel? At the very least we need to support errata branches. The RE team has expended a lot of effort to provide a mechanism to handle critical problems found post-release. We don't want to negate this by telling users that they have a choice of either using driver X or fixing hole Y. Unfortunately, in the rare case where an errata fix affects a kernel API/ABI, the change is probably critical to fixing the problem. This would require the FreeBSD fix to be co-ordinated with the driver vendor. I think that guaranteeing operation in -STABLE is probably impractical - though API/ABI changes would need to be flagged to vendors so they could test drivers for the next FreeBSD release. -- Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050225093917.GA90508>