[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Changes in formal naming for NetBSD porting effort(s)

On Wed, Dec 17, 2003 at 01:57:15PM -0700, Joel Baker wrote:
> On Wed, Dec 17, 2003 at 12:44:07PM -0500, Nathan Hawkins wrote:
> > On Fri, Dec 12, 2003 at 02:58:42PM -0700, Joel Baker wrote:
> > > I really need to sit down and write a proposal / patches for NetBSD to
> > > support the 'vendor' sysctl tree, that can be checked usefully. Since that
> > > would be the canonical way of testing this (a 'debian' vendor could have a
> > > sub-field indicating which sort of port it was).
> > 
> > There is one possible problem with that. It occurred to that it is quite
> > possible now to run regular freebsd in a jail or chroot on a debian
> > freebsd box, and vice versa. I assume the same is true for the netbsd
> > port. If we use sysctl or uname to make the distinction, that jail or
> > chroot usage will be affected.
> This is, in fact, an issue with my chroot environment which I have to
> spend some amount of effort to work around.

I think it's probably a good idea to mark the kernel, like you're
describing. I suspect NetBSD might be more than happy with that idea.
I'm just concerned about actually using that in userspace for things
like config.guess. I think that might be a mistake.

We could always have config.guess test for the existance of
/etc/debian_version, or other files from required packages. Something
like that should reliably work in a jail or chroot.

> The nicer solution, IMO, would be user-mode-<foo>BSD, akin to
> user-mode-linux. Especially when combined with bind mounts, this has the
> potential to be very powerful, indeed.

Hmm. Maybe someone out there would like to make a NetBSD port like UML.
That'd be very cool, especially if it ran on Linux and FreeBSD as well.

I'd still rather keep the ability to work in jails and chroots. The
jails are probably more useful on freebsd, but chroots make it a lot
easier for people to try this stuff out.

> Unfortunately, I'm still not entirely clear on what all would need to be
> done, to accomplish this properly.

I don't know. Sounds like a lot of work.


Reply to: