kernel features MIB

[John Baldwin]

On Friday 28 December 2007 12:17:00 pm Max Laier wrote:
> 
> Am Do, 27.12.2007, 23:04, schrieb John Baldwin:
> > One of the things we have at work is a kern.features sysctl MIB that
> > contains
> > nodes to indicate if a named feature is present.  For example, on i386 we
> > have kern.features.pae and we auto enable -DPAE for kernel modules if the
> > currently running kernel is using PAE using that sysctl.
> >
> > One of the patches I want to commit soon is support for handling
> > shm_open/shm_unlink directly in the kernel via swap-backed VM objects (the
> > long-heralded memfd stuff).  I would like to have the sysctl MIB so that
> > libc's for older releases (e.g. libc.so.6) could use the syscalls if they
> > are
> > available so that shm segments are shared between compat apps (e.g. 4.x or
> > 6.x) and up-to-date apps.
> >
> > At work we don't have a pretty API for this at all, but I'm thinking for
> > FreeBSD we can do this:
> >
> > FEATURE(foo, "description of foo")
> >
> > which is a macro to create the 'kern.features.foo' node and set it to 1.
> > Then
> > we could have a routine in libc:
> >
> > int	feature_present(const char *name);
> >
> > That returns a boolean to indicate if a given feature is present or not by
> > invoking sysctlbyname(3), etc.
> >
> > Any objections to the idea?
> 
> Sounds like a good idea indeed.  What about modules, though?  Would it
> make sense to have something ident/strings parseable in the .kld to
> identify features provided by that module?  feature_present (or
> _available) could search the default module paths and return which module
> needs to be loaded.  This could depend on FEATURE(kld, ...) and maybe
> kern.securelevel.

You could have a userland tool that parses the linker set for sysctl's and 
uses the name of the symbol to figure this out if that was desired.  Modules 
already have the MODULE_DEPEND stuff available that could be used, but I'm 
thinking about things that aren't in modules.

-- 
John Baldwin