DragonFly kernel List (threaded) for 2007-01
Re: Re vkernel and all
:Regarding the vkernel work and other exciting things happening: how
:(if at all) will this affect the scope of the application base
:supported by dragonfly?
My original reasons for wanting to have a working virtual kernel
have not changed. For me, having a working vkernel reduces the
engineering cycle time for testing new kernel code from 5 minutes
to 5 seconds. I decided it was a must-have development tool to
be able to make any progress on my upcoming clustering work.
What other uses are there? Well, any kernel development done by anyone
on any subsystem that does not directly involve hardware will benefit
*hugely* from the virtual kernel feature. Filesystems, Networking,
Clustering, etc. The linux folks apparently have used the linux UML
primarily for kernel development.
For real world apps, clearly anyone farming out server style services
would be well served by having this sort of feature. I believe this is
the other main use of UML in Linux, but it must also be considered in
the type of clustered environment that I intend to build for DragonFly.
I don't expect performance in such an environment to be great, at least
not initially, but that isn't the point of being able to do it, at
least not at the beginning.
Anyone for which security is far more important then performance
would also be well served. The load on the machines in my server room
is fairly low... performance isn't an issue. I have all those machines
primarily for security separation and resource management purposes.
For other real world apps... well, it depends on what kind of app it is
and what kind of performance is needed. As has been mentioned, the
performance of this sort of abstraction suffers when it comes to anything
that requires a lot of page table manipulation or makes a lot of system
calls. Strangely enough, cpu-bound programs such as compilers tend NOT
to suffer anywhere near as badly.