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

Re: Re: Debian BSD.. cool idea



I recall waay back on Jan 31 when Raul Miller wrote:

> You're right.  Though that's a fairly constrained case and I
> think it would be fine to have a kernel-specific set of kld*s.
> 
> And, I guess that means that linux apps which use /proc/ aren't
> going to work.

There's more to it than that though. A lot of basic system processes
(bound up in util-linux right now) would need to be the FreeBSD
equivalents, and they'd have to be built for the same kernel version.

> Debian Linux already has an analogous situation for various 

[cut off?]

> > Also, things like 'jail' don't even exist in Linux (wow jail is cool!
> > =).
> 
> You mean this thing?
> 
> $ apt-cache search jail
> jail - Just Another ICMP Logger
> $

No, this thing..

>] apropos jail
jail(2) - Imprison current process and future decendants

This is different, it's a FreeBSD 4.0 kernel-based thing. It's much more
powerful than chroot but similar. It's chroot plus it restricts root's
capabilities and makes only processes in the same jail and one IP address
accessable. I'm guessing this is for building virtual machines under a
main machine, which is what we're doing where I work...

> > Things like 'ps' and 'top' use BSD-specific methods since the POSIX
> > committee in all their wisdom decided against specifying a way to
> > introspect the system. So you'd need these too.
> 
> It's not so pleasant if independent versions of such things have to be
> resupplied for every kernel.  Do they?

Unfortunately, yes. That's the kernel dependencies I was talking about
working around (and that the other Dan was talking about).

> > That brings back the kernel dependencies. And unfortunately, basic
> > system programs like init and killall tend to need to look at the
> > process listing one way or another, among other kernely things.
> 
> Might be worth writing a /proc/ emulator then...
> 
> But yeah, that's work.

It's also not strictly FreeBSD (kernel) anymore. That's heading towards a
kernel code fork of sorts.


Reply to: