Date: Tue, 15 Jun 2010 12:04:55 -0400 From: John Baldwin <jhb@freebsd.org> To: Alexander Leidinger <Alexander@leidinger.net> Cc: Ilya Bakulin <webmaster@kibab.com>, soc-status@freebsd.org Subject: Re: [Status update] sysctlreg project Message-ID: <201006151204.56034.jhb@freebsd.org> In-Reply-To: <20100615164806.1731241umjjyw2is@webmail.leidinger.net> References: <20100614151113.17a1c368@kibab.com> <201006150958.29782.jhb@freebsd.org> <20100615164806.1731241umjjyw2is@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 15 June 2010 10:48:06 am Alexander Leidinger wrote: > Quoting John Baldwin <jhb@freebsd.org> (from Tue, 15 Jun 2010 09:58:29 -0400): > > > On Tuesday 15 June 2010 3:24:52 am Alexander Leidinger wrote: > >> Quoting John Baldwin <jhb@freebsd.org> (from Mon, 14 Jun 2010 16:36:02 > > -0400): > >> > >> > Hmmm, is this spoofing a desired feature? If so, perhaps it should > >> > be done in > >> > userland via environment options that affect the feature_present(3) API in > >> > libc? (In that case you would write a little feature_present(1) util that > >> > uses the userland API and use this instead of direct sysctls in ports, > > etc.) > >> > >> Kris listed spoofing (no mention if only "spoof-off" or also > >> "spoof-on", but for "spoof-on" when the feature is not present in the > >> kernel we can only come up with scenarios where it will hurt) as > >> desired for the ports collection. > >> > >> Regarding an userland utility: > >> 1) To be able to spoof-off a feature in a jail (from the host, not > >> inside the jail) without the possibility that the jail-root is able to > >> turn it on again, a feature_present(1)+env will not help much, you > >> need to do this in the kernel. > >> 2) With 1) in mind, why another tool for the ports to query the > >> status, sysctl is enough. > > > > If you wish to do 1) though it seems wrong to have to have the same spoof > > settings for the entire host. It would seem that you would want to have > > different feature sets in different jails. So far the env approach has been > > good enough for spoofing uname data for ports builds. I see no reason why it > > shouldn't be equally functional for feature test overrides for ports builds. > > I agree that the env approach is enough if it is 'just ports'. What is > your proposal? Just taking care about ports and forget about jails in > the GSoC project? Based on Kris's description on the project page, I believe that he is only interested in this for the ports build angle. They use env vars to fake the uname output so that a jail of an older version builds as if it was truly running the older version. To me this seems to fit well with that. Part of the problem with doing the spoofing in the kernel is that to do it right requires making the spoof values jail-aware. The simplest way to do this is to probably hook into vimage. However, that is quite a bit of work and complexity to handle non-ports cases that may never occur in practice. I think for now the focus should be on solving the ports case which can be done rather simply in userland. If in the future someone comes up with a practical use case for spoofing these values that the env vars does not solve, then this could be revisited. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201006151204.56034.jhb>