Replying to two messages at once...

> > NetBSD would certainly be better suited to this than Linux - we could
> > have a port-netbsd architecture ;-)
> having it as an architecture does sound like a good idea.  where else
> would you put it? :-)

I was just thinking how confusing it would be to have NetBSD listed down
the right side of the web page as a supported arch...

> > As someone else said though, why?
> why eat toast?

Well, in my case - for the Jelly, not for the toast. A project of that
scale ought to be a means, not an end - IMO.

> i like it because it boots a lot faster than a real kernel, and makes it
> easier to simulate crash scenarios (kill -9 pidofusermodekernel)

It would run a lot slower, and not be useful for most of the real things
you want to test crashes for - driver development, hardware debugging...

And it wouldn't boot any faster, it would likely boot slower I'd think -
minus PROM time.

On Mon, Dec 11, 2000 at 11:08:24PM +0100, beez wrote:
> possible uses could be: trying out 'dangerous' stuff in a kernel. Having an
The most dangerous stuff (crash-causing) is likely to be hardware
interaction, which you won't really be doing... And you can't test
drivers for things that the underlying system doesn't know how to
emulate...

> even more secure layer for possible malicious userspace programs (basically
> a kernel 'chroot'), if one could port the kernel to other OS's (win32) that

If you're running the same version in both layers, one exploit can
likely be used to go all the way from luserland to kernel.

> would even be neater, I'd love to run a NetBSD session from a win32 dosbox

Then you really can't guarantee multitasking etc...

> maybe a userland kernel would be a nice way for students to start to learn 
> how NetBSD (or *nix in general) works. Maybe it can also function as
> a easy 'template' for new NetBSD ports ...

It wouldn't be a good template - as it would have a lot of odd
abstractions no other hardware would require.

> > If you're abstracting the underlying hardware, abstract the clock
> Hrm, I'm probably lacking in OS knowledge here, isn't stuff like
> task switching dependant on a an external (hardware/thread) source.
> As far as I know, a callback is hooked on the clock interrupt and
> that callback controls things like switching tasks ... no?

Yes, but you won't have real interrupts - they're abstracted.

> > > 4. Drivers - I don't see a problem here but I might be missing something,
> Very true, indeed there will be many problems in various drivers,
> NetBSD (like any *nix) requires low-level ethernet/ip/tcp adressing
> while a host-OS might not be able to provide that. So I will need
> to cut corners here, maybe by partly emulating it. Practically this
> means that porting the userland kernel to other *nix's is probably
> not too problematic. Any non-posix system will be much more problematic
> (but not undoable).

It depends on whether you're thinking userland process, or 'virtual
machine'. You can of course do anything you want with a virtual machine,
but with a lot more overhead.

> > As someone else said though, why?
> It's just plain old fun! ;-)

Not enough fun for me to be interested in working on... but see where
the thread goes.

-- 
David Maxwell, david@vex.net|david@maxwell.net -->
If you don't spend energy getting what you want,
	You'll have to spend it dealing with what you get.
					      - Unknown