From owner-freebsd-hackers@FreeBSD.ORG Fri May 6 20:35:32 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0EE6C16A4D4 for ; Fri, 6 May 2005 20:35:32 +0000 (GMT) Received: from gate.bitblocks.com (bitblocks.com [209.204.185.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4B5443D97 for ; Fri, 6 May 2005 20:35:31 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost [127.0.0.1]) by gate.bitblocks.com (8.13.3/8.13.1) with ESMTP id j46KZVu0041406; Fri, 6 May 2005 13:35:31 -0700 (PDT) (envelope-from bakul@bitblocks.com) Message-Id: <200505062035.j46KZVu0041406@gate.bitblocks.com> To: David Parfitt In-reply-to: Your message of "Fri, 06 May 2005 15:56:03 EDT." <3c220db005050612561d05cefa@mail.gmail.com> Date: Fri, 06 May 2005 13:35:31 -0700 From: Bakul Shah cc: freebsd-hackers@freebsd.org Subject: Re: FS impl. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2005 20:35:32 -0000 > I have been trying to write my own UFS-like filesystem > implementation for fun. I had read somewhere that UFS was developed in > user space (correct me if I'm wrong on that one) and then moved over > to kernel-space. I was wondering if there are any existing facilities > in the kernel source tree that would allow me to develop an fs in user > space easily or with a little tweaking? As of right now, I have to > develop, compile, panic, reboot, debug etc. which is frustrating and > time consuming. A stub FS that directs all vfs calls to userland would be a handy thing.... Similarly a stub disk -- one should be able to debug support for Petabyte size disk without having to buy one. As for shortening the compile/debug/panic/reboot cycle, you can use qemu. Once a guest os is installed on a disk-image, you can do this: # qemu -s disk-image # cd /usr/obj/usr/src/sys/ # gdb kernel.debug (gdb) target remote localhost:1234 That is it! No need to set up serial console or anything. I haven't tried this but I guess this should work: If you make the FS module a kernel module, and use qemu's snapshot feature, after a crash you can reload from your image right before FS module loading and go from there. Now with a kernel module `kqemu', qemu runs approx twice as slow as real h/w for usercode (as opposed to about 25 times slower without kqemu).