GSoC: registration of optional kernel features via sysctl: a question to the community

jhell jhell at dataix.net
Wed Jun 9 13:14:01 UTC 2010


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


More information about the freebsd-hackers mailing list