On Saturday 22 March 2008 11:20:07 am Oliver Fromme wrote:
> M. Warner Losh wrote:
> > In message: <[EMAIL PROTECTED]>
> >
> > Oliver Fromme <[EMAIL PROTECTED]> writes:
> > : The vkernel feature has certainly benefits, e.g. the fact
> > : that you can attach to it with standard gdb
M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Oliver Fromme <[EMAIL PROTECTED]> writes:
> : The vkernel feature has certainly benefits, e.g. the fact
> : that you can attach to it with standard gdb and use the
> : familiar debugging facilities, which can attract more
In message: <[EMAIL PROTECTED]>
Oliver Fromme <[EMAIL PROTECTED]> writes:
: The vkernel feature has certainly benefits, e.g. the fact
: that you can attach to it with standard gdb and use the
: familiar debugging facilities, which can attract more
Can't you say qemu -s and attach gdb t
>From: Matthew Dillon
>To: John Baldwin <[EMAIL PROTECTED]>
>:Except that you still need "real" hardware concurrency to see some races and
>:that is important for testing. I'd worry about the overhead of any
>
>Hardware and vkernel/qemu environments exercise different code paths
>and d
:Except that you still need "real" hardware concurrency to see some races and
:that is important for testing. I'd worry about the overhead of any
:non-hardware assisted virtualization basically enforcing more serialization
:and coherency than is present in real-world systems meaning that code w
On Wednesday 19 March 2008 06:48:46 pm Matthew Dillon wrote:
> :Matthew Dillon wrote:
> :> :Matt,
> :>
> :>...
> :>
> :> :Don't you use something like VMWare for development and debugging?
> :>
> :> We use vkernel's for development and debugging. Pretty much
> :> everything except hardware de
:Matthew Dillon wrote:
:> :Matt,
:>...
:> :Don't you use something like VMWare for development and debugging?
:
:> We use vkernel's for development and debugging. Pretty much everything
:> except hardware device driver development can be done using a vkernel...
:
:Does that include tryi
Hi,
Sorry for jumping in here, but I've seen several people
talking about that "5 seconds to reboot" thing ...
Are you aware that a standard FreeBSD kernel also takes
just 5 seconds to reboot within qemu? And that's even
when _not_ using the kqemu accelerator module.
I've used qemu a lot for deb
On Sun, Mar 16, 2008 at 11:42:57AM +0200, Jordan Gordeev wrote:
> > vkernel is similar to User Mode Linux technology. You can boot vkernel as a
> > user mode process. I think it will be good to have similar in FreeBSD.
> > There are several links:
> > http://leaf.dragonflybsd.org/mailarchive/users/
Matthew Dillon wrote:
:Matt,
...
:Don't you use something like VMWare for development and debugging?
We use vkernel's for development and debugging. Pretty much everything
except hardware device driver development can be done using a vkernel...
Does that include trying to get rid
Jordan Gordeev wrote:
Matthew Dillon wrote:
We use vkernel's for development and debugging.
...
One interesting side-effect of having a vkernel so easily accessible
is that it opens up kernel development to normal programmers. More
DragonFly developers have been dipping their fi
Matthew Dillon wrote:
:Matt,
:
:We use VMWare Server at work. It does not have the same nice image management
interface and/or video capture as commercial counterparts. However, it is is
free and testing on it helps us out big time. We never concluded whether it
maked sense to pay for VMWare
:> In all three cases the emulated hardware -- disk and network basically,
:> devolves down into calling read() or write() or the real-kernel
:> equivalent. A hypervisor has the most work to do since it is trying to
:> emulate a hardware interface (adding another layer). XEN has
Matthew Dillon wrote:
I guess my problem is that you are holding this up as a red flag when
it isn't even remotely close to being one.
What I have said is that the dragonfly vkernel work is the interesting
beginning of a project, but that further work needs to be done before
the proj
Kris Kennaway wrote:
Matthew Dillon wrote:
:I don't think there's an issue that needs solving, GCC has -nostdlib
and :-fno-builtin for precisely this reason.
You are missing the point entirely. The point is to allow the
vkernel
to use libc, aka allow it to be compiled, linked, and r
:
:If your goal is to link vkernels with libc then by definition you are
:forced to resolve the namespace conflicts, but I don't see this as a
:necessary goal. A minimal standalone libkernel would do the same thing
:without requiring global changes to the kernel namespace, which would
:likely
Matthew Dillon wrote:
In all three cases the emulated hardware -- disk and network basically,
devolves down into calling read() or write() or the real-kernel
equivalent. A hypervisor has the most work to do since it is trying to
emulate a hardware interface (adding another layer
Matthew Dillon wrote:
:I don't think there's an issue that needs solving, GCC has -nostdlib and
:-fno-builtin for precisely this reason.
You are missing the point entirely. The point is to allow the vkernel
to use libc, aka allow it to be compiled, linked, and run as a normal
user
:I don't think there's an issue that needs solving, GCC has -nostdlib and
:-fno-builtin for precisely this reason.
You are missing the point entirely. The point is to allow the vkernel
to use libc, aka allow it to be compiled, linked, and run as a normal
user process. What is your
Maslan wrote:
Hi all,
Aren't we working on a FreeBSD/Xen port ???
I think we don't need a Linux like KVM or DragonFly's vkernel, if we
could run FreeBSD in dom0.
I agree that people interested in virtualization will get the most
return on investment if they contribute to the Xen port, large a
Matthew Dillon wrote:
:> Well, I don't think I would agree with your assessment but,
:> particularly, the way vkernels are implemented in DragonFly is NOT
:> in the least disruptive to kernel source.
:
:I was referring to the decision you made to rename all of the kernel
:functions t
:> Well, I don't think I would agree with your assessment but,
:> particularly, the way vkernels are implemented in DragonFly is NOT
:> in the least disruptive to kernel source.
:
:I was referring to the decision you made to rename all of the kernel
:functions that conflicted with lib
Hi all,
Aren't we working on a FreeBSD/Xen port ???
I think we don't need a Linux like KVM or DragonFly's vkernel, if we
could run FreeBSD in dom0.
Thank a lot
On Mon, Mar 17, 2008 at 3:09 AM, Kip Macy <[EMAIL PROTECTED]> wrote:
> On Sun, Mar 16, 2008 at 8:06 PM, Adrian Chadd <[EMAIL PROTECTED]
On Sun, Mar 16, 2008 at 8:06 PM, Adrian Chadd <[EMAIL PROTECTED]> wrote:
> On 16/03/2008, Robert Watson <[EMAIL PROTECTED]> wrote:
>
> > Another avenue to consider is the Linux KVM virtualization technology,
> which
> > is seeing a high level of interest in the Linux community and sounds
> >
On 16/03/2008, Robert Watson <[EMAIL PROTECTED]> wrote:
> Another avenue to consider is the Linux KVM virtualization technology, which
> is seeing a high level of interest in the Linux community and sounds
> increasingly mature and well-exercised. It would also offer interesting
> migration be
Matthew Dillon wrote:
:Finally, the way vkernels were implemented in dragonfly was *very*
:disruptive to the kernel source (lots of function renaming etc), so it
:is likely that this would also have to be completely reimplemented in a
:FreeBSD port.
:...
:Kris
Well, I don't think I would
:Finally, the way vkernels were implemented in dragonfly was *very*
:disruptive to the kernel source (lots of function renaming etc), so it
:is likely that this would also have to be completely reimplemented in a
:FreeBSD port.
:...
:Kris
Well, I don't think I would agree with your assessme
Jordan Gordeev wrote:
Hello!
I am a student who considers applying for Google's Summer of Code
programme.
One of my ideas for a GSoC project has the following synopsis:
Add virtual kernel (vkernel) support to FreeBSD for the i386 and
amd64 architectures.
The vkernel support in question i
On Sun, 16 Mar 2008, Andrey V. Elsukov wrote:
16.03.08, 09:30, "David O'Brien" <[EMAIL PROTECTED]>:
Add virtual kernel (vkernel) support to FreeBSD for the i386 and amd64
architectures.
The vkernel support in question is the one found in DragonFlyBSD.
Not being up on DragonFlyBSD, can you
Andrey V. Elsukov wrote:
16.03.08, 09:30, "David O'Brien" <[EMAIL PROTECTED]>:
Add virtual kernel (vkernel) support to FreeBSD for the i386 and amd64
architectures.
The vkernel support in question is the one found in DragonFlyBSD.
Not being up on DragonFlyBSD, can you better desc
On Sun, 16 Mar 2008 01:30:25 -0500, David O'Brien <[EMAIL PROTECTED]>
wrote:
On Sat, Mar 15, 2008 at 02:58:40PM +0200, Jordan Gordeev wrote:
I am a student who considers applying for Google's Summer of Code
programme.
One of my ideas for a GSoC project has the following synopsis:
Add virt
16.03.08, 09:30, "David O'Brien" <[EMAIL PROTECTED]>:
> >Add virtual kernel (vkernel) support to FreeBSD for the i386 and amd64
> > architectures.
> >
> > The vkernel support in question is the one found in DragonFlyBSD.
> Not being up on DragonFlyBSD, can you better describe what "vkernel" i
On Sat, Mar 15, 2008 at 02:58:40PM +0200, Jordan Gordeev wrote:
> I am a student who considers applying for Google's Summer of Code
> programme.
> One of my ideas for a GSoC project has the following synopsis:
>
>Add virtual kernel (vkernel) support to FreeBSD for the i386 and amd64
> archite
33 matches
Mail list logo
