Quoting jhell <[email protected]> (from Wed, 09 Jun 2010 10:54:16 -0400):
That would lead me to believe that the elimination of this sysctl would
be better suited to solve the outcome of cases like this.
And leads me to believe that it still rests on the end-user to tell
whether or not they have that compatibility layer compiled in.
Like I stated more towards the end of my last message "I believe"
checking __FreeBSD_version should suffice and leave the final result up
to the end-user as GENERIC will have the COMPAT_FREEBSD{N} layers
compiled in that it needs or can support or are recommended.
Being that this is a broad scenario and many different compilations of
kernels could be used I still do not see a need to test for every one of
them if an adequate means already exists. GENERIC in any case should be
the kernel that is depended on and testing against __FreeBSD_version for
what COMPAT versions are supported.
Maybe there is a misconception of what is being done.
We will have something like (out of the top of my head, do not nail me
on the spelling or a particular feature):
kern.features.compat_4
kern.features.compat_6
kern.features.softupdates
kern.features.ufs_snapshots
As soon as something is active in the kernel (directly compiled in or
via a module), the corresponding kern.features.XXX entry will show up
(with a value of 1). The spoofing feature which Ilya was talking about
in this thread will for sure allow to mask an existing feature away.
__FreeBSD_version is not adequate at all for things which require a
feature to be present in the kernel (can be removed in a custom
kernel) and are required at run-time (build-time checks do not help
here, just think about building and installing a program, and then
changing the kernel config and installing a new kernel).
Bye,
Alexander.
--
"Don't worry. Clemenza is OK. It's Paulie."
-- Santino Corleone, "Chapter 4", page 93
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[email protected]"
