development

development

[Grant Miner]

Hey,
How do you guys write your file system?  Do you compile and reboot, or 
use an emulator?

Re: development

[Hans Reiser]

Grant Miner wrote:

> Hey,
> How do you guys write your file system?  Do you compile and reboot, or 
> use an emulator?
>
>
We use UML for everything it can be used for.

-- 
Hans

Re: development

[Tom Vier]

i was just thinking about this the other day.

On Tue, Jan 06, 2004 at 11:25:18PM +0300, Hans Reiser wrote:
> We use UML for everything it can be used for.

what about putting the core code in a lib and using a file for storage? once
it stabilizes, remove the userland stuff and hook it up to the vfs.
actually, you could write it all for the vfs and the blk layer. just
emulated them in userspace. the app could load the lib and call the vfs
entry points. the core could use routines in a blkemu.c module that would
translate them to regular read/write calls.

-- 
Tom Vier <tmv@comcast.net>
DSA Key ID 0xE6CB97DA

Re: development

[Andreas Dilger]

On Jan 06, 2004  21:23 -0500, Tom Vier wrote:
> On Tue, Jan 06, 2004 at 11:25:18PM +0300, Hans Reiser wrote:
> > We use UML for everything it can be used for.
> 
> what about putting the core code in a lib and using a file for storage? once
> it stabilizes, remove the userland stuff and hook it up to the vfs.
> actually, you could write it all for the vfs and the blk layer. just
> emulated them in userspace. the app could load the lib and call the vfs
> entry points. the core could use routines in a blkemu.c module that would
> translate them to regular read/write calls.

Except UML already "emulates" the VM, threads, locking, etc perfectly in
user space.  There is basically no point in trying to create an emulator
better than UML, since for filesystem and other "non-hardware" kernel
development it is a perfect kernel emulator.  The only thing you don't
(currently) get is SMP support, so no spinlocks, etc.

Also, with just a simple library you can't really run applications against
it unless you also compile the applications where the library replaces
the stdio and normal Unix IO calls.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: development

[Alexander G. M. Smith]

Tom Vier wrote on Tue, 6 Jan 2004 21:23:30 -0500:
> On Tue, Jan 06, 2004 at 11:25:18PM +0300, Hans Reiser wrote:
> > We use UML for everything it can be used for.
> 
> what about putting the core code in a lib and using a file for storage? once
> it stabilizes, remove the userland stuff and hook it up to the vfs. [...]

I just use lots of dprintf statements to write debugging messages out to
a serial port and a log file, and avoid writing buggy code in the first
place (lots of sanity checks, etc).  But that was for a fancy RAM file
system, a one person project, not something as big as ReiserFS.  I also
had a user level file system test program which was useful for comparing
how different file systems handled, well, just about everything.  Old
screen shot at http://web.ncf.ca/au829/BeOS/AGMSRAMFSMounter.screen.gif

Admittedly I did develop some components in user-land, like the pattern
matching code or the AVL trees.  But most debugging (there wasn't much)
just needed print statements.  I also know of other people that use a
VFS simulator / test harness for their file system code.  But that's on
BeOS so it won't be too useful for Unix style development.

- Alex

RE: development

[Burnes, James]

I wonder if they could use user-mode linux.

Jim Burnes

-----Original Message-----
From: Grant Miner [mailto:mine0057@mrs.umn.edu] 
Sent: Tuesday, January 06, 2004 1:13 PM
To: reiserfs-list@namesys.com
Subject: development

Hey,
How do you guys write your file system?  Do you compile and reboot, or 
use an emulator?

Development

[lk]

Hi all,

Ok, pre-email warning : this might get some people annoyed.
However, I do not mean to troll or start flamewars. Please,
bear with me.

I grow increasingly worried about the speed that the kernel
development is going at. No, I'm not saying "get things done
faster! I want more features! Support my usb joystick now!!"
I'm worried by the amount of drivers that are included in a
stable kernel release that are not marked "Experimental" and
yet are broken, as well as major compile problems in stable
releases.

Things such as show_trace_task() in only the i386 tree,
the Xircom net drivers freezing, APM broken on VIA chipsets
(and my dell inspiron 8100) - this should be working in a
stable release.

I'm worried that we're pushing things too fast and not taking
the time to test. The famous broken loopback in 2.4.14 and
the nasty symlink bug in 2.4.11 come to mind.

Perhaps we need to take a little more time before stamping
things as "stable"? Otherwise our beloved Linux might go
the way of Windows - "use at your own risk". I'd really
hate to see that.

Thanks,

MikeH