Date: Thu, 20 Mar 2008 08:54:25 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-hackers@freebsd.org Cc: walt <w41ter@gmail.com> Subject: Re: vkernel & GSoC, some questions Message-ID: <200803200854.26258.jhb@freebsd.org> In-Reply-To: <200803192248.m2JMmkEn045986@apollo.backplane.com> References: <200803172158.m2HLwPSI021438@apollo.backplane.com> <frphq3$vce$1@ger.gmane.org> <200803192248.m2JMmkEn045986@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 device driver development can be done using a > :> vkernel... > : > :Does that include trying to get rid of the BGL, for example? > > Yah, the SMP stuff works the same in a vkernel as it does in a real > kernel. If anything, the vkernel is even more sensitive to conflicts > since vkernel 'cpus' are threads on the real system and can wind up > being scheduled as time-share (for example, booting a 4-cpu vkernel > on a single-cpu platform). 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 will work fine in the virtual environment and only break on real hardware. For example, when I worked on the rwlock implementation for FreeBSD 6/7, I wrote a custom kernel module that banged on the locks a lot and used KTR traces to verify that every single code path in the lock and unlock routines was exercised on a 4-way machine. I do think that vitualized environments can certainly be useful for many things (I used qemu for the recent GPT boot stuff and BTX changes and being able to single step in gdb for that was extremely useful and time-saving), but with concurrency races I think it is very important to make sure there is a lot of testing on full-speed, concurrent hardware. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200803200854.26258.jhb>