Date: Wed, 02 Apr 1997 10:27:35 +0500 From: "A JOSEPH KOSHY" <koshy@india.hp.com> To: "Justin T. Gibbs" <gibbs@plutotech.com> Cc: freebsd-current@freebsd.org Subject: Re: Kernel Module System Message-ID: <199704020527.AA134058855@fakir.india.hp.com> In-Reply-To: Your message of "Tue, 01 Apr 1997 21:18:47 MST." <199704020420.VAA18373@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>> ""Justin T. Gibbs"" <gibbs@plutotech.com> writes Hi, > You don't want a single version number really. You want one for each > subsystem that an LKM may depend upon. For example, the SCSI system might Yes, but there is a tradeoff between complexity and utility. If we basically want to prevent a 2.2 LKM being loaded into a 3.1 kernel, (or vice-versa) a simple version number would suffice. This would trap say, attempts by a user to load in a third-party LKM into his/her FreeBSD kernel. In the absence of such a mechanism; the user would know that the LKM is mismatched only when something catastrophic happens. This is really a release engineering issue, not a development one, and I think it may make it easier for third party vendors to offer binary only LKM addons for FreeBSD. Such a LKM versioning system is probably not relevant for people following -current; the traditional method of rebuilding LKMs every now and then would probably still suffice for them. I was initially looking a `kernel signature' derived from the sizes of key data structures, version numbers of sources etc. However, further thought showed that such a solution would really be overkill for the intended purpose and a single version number would probably suffice. Koshy <koshy@india.hp.com> My Personal Opinions Only.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704020527.AA134058855>