Date: Wed, 09 Jun 2010 09:13:56 -0400 From: jhell <jhell@dataix.net> To: Ilya Bakulin <webmaster@kibab.com> Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC: registration of optional kernel features via sysctl: a question to the community Message-ID: <4C0F9394.9030202@dataix.net> In-Reply-To: <20100609121453.095d92b4@kibab.com> References: <20100609121453.095d92b4@kibab.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06/09/2010 04:14, Ilya Bakulin wrote: > Hi hackers! > > While discussing my project's implementation details with my mentor, > Alexander Leidinger, we've found that one of the ideas needs to be discussed with community, > to find out possible use cases. > That is, if it should be possible to spoof non-existing features. For > example, if currently running kernel doesn't support FreeBSD 5.0 compat > layer, "kern.features.compat_freebsd5" will be absent when querying > features list. The question is -- are there any cases when we want > "kern.features.compat_freebsd5" be present? If some feature is not in > kernel, then presenting its existence to the userland is useless > and may be even harmful, if, for example, some application relies on this feature. > Or there are some scenarios where such cheat is useful? > I can not think of any viable reason why one would want to "spoof" this when it is not available. To have this be present and set to a value of '0' would make sense for telling end-user program that its not available. Since a generic kernel is already built with the compatN layers that it supports I believe it would be best to look at __FreeBSD_version which should be kern.osreldate to see if that layer of compatibility is available at all and then leave it up to the end-user to enable it if they have built their own private kernel. Another thought that had come to mind was to make that sysctl an array of values for the layers of compatN that exist in the kernel. 1). Address [0] of the array is set to 1 if any compatN is available. 2). Further corresponding addresses 1 - N would correspond to _FREEBSD1 to FreeBSDN. "This is why COMPAT_FREEBSD32 is bad!" 3). If a compat version becomes unsupported set its array value to null. This would allow someone to be able to check against address [0] which should always exist and discontinue further checks to see what versions are available. Although it suggests subverting actually doing the work on the software writers part and checking against __FreeBSD_version to see what versions are available in a 'GENERIC' kernel. Just a thought but I would rather see an array of values than 3 - 4 separate sysctls. Kind regards & happy hacking, -- jhell
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C0F9394.9030202>