Jail uname spoofing / misc

[Chris Turner <c.turner@xxxxxxxxxxxxxxxxxxx>]

I'm finally getting around to doing 1.12 upgrades, and have setup a 
separate machine to do my bulk package builds / upgrades etc,
so as not to disrupt my 'dev server' while things are being
built / tested

However, this seems kind of wasteful - the only purpose of this machine
is to build packages against a specific release..

And since building packages for a particular release generally requires 
only the userland, appropriate headers and correct 'uname' output - so:

it seems like if spoofing uname is configured inside a jail,
the next (or previous..) release can be installed into a jail and
used for building / testing packages without the overhead of a VM or 
maintaining a separate physical host

I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:

- update struct jail to add a 'osrelease' string
  (implies bumping 'jail api' to 2?)
- update jail(8) to actually pass this information along
- update sys_uname to test ucred for jailed processes, and
  use the struct jail osrelease if appropriate
- similarly update sysctl kern.osrelease to support jail spoofing
  (if possible - didn't get this far in the research yet)
  could be less of a problem for builds, as I think most things use
 uname(1) ... but good to keep the environment consistent I suppose..

I'm still a bit confused as to how 'osrelease' is defined - everything
I'm finding is showing up as extern char[] .. perhaps this is something 
in the build I'm not familiar with?

also,

is the so-called 'stupid hackery' in sys_uname needed still?

Before I start any coding, does this:

- sound like something useful
- sound like the right approach

Thinking this could have wider useful implications e.g. for pkgbox
& so on -  for example setting up automated bulks w/various combinations 
of pkgsrc and releases, etc.

Cheers,

- Chris