Date: Tue, 5 Jan 1999 18:47:29 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dyson@iquest.net Cc: tlambert@primenet.com, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Message-ID: <199901051847.LAA10199@usr02.primenet.com> In-Reply-To: <199901050437.XAA26494@y.dyson.net> from "John S. Dyson" at Jan 4, 99 11:37:41 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Also, the FreeBSD VFS/VM code already supports the ability to > > > have non-mapped buffers (and has for 2years.) There is alot in there that > > > might make the complexity look excessive, but that is only because there > > > are features in there that are almost ready to go. > > > > Actually, I think some of the tighness of VM system integration into > > the VFS code is a mistake. > > I think that since the amount of interaction needed is now understood, > a rearchitecting of the code would valuable. IMO, the VFS and VM code > need to be bound in very intimate ways, and most seperation between > the two is artificial. My guess is that it is probable that the efforts > had historically been split between VFS and VM, and the interfaces were > defined without both parties understanding the needs. Since that is > understood now, things should be reworked. Hmmm. I don't really buy this for the general case, which I believe is still stacking layers that don't access local media. For local media FS's, things which actially do I/O through a page fault, this is probably correct. The point in abstraction, however, is not artificial, unless you only consider one *BSD. If you want to leverage the total *BSD hacker base to do FS (or any other kind of) work such that it's applicable to your particular flavor of the month of *BSD, then you need that type of abstraction. I really think that the main FS work as time goes on will be in stacking layers, and not in local media FS's. Sure, there will be some architectural work to be done; seperation of directory hierarchy management from file object management from (probably) a low level variable granularity block store on which you could build a log structured or other kind of FS. Maybe a seperation of the soft updates dependency relationship code from the actual implementation using a registration mechanism, so that going forward you can implement transactioning as a stacking layer that asserts a dependency relationship and/or resolve dependencies implied between stacking layers (e.g. for ACL support). But the amount of things you can do solely within a stacking layer is amazing. You see glimmers of that stuff, either by following John Heidemann's student's work on compressing and cryptographic layers, or even in FreeBSD with some of the stuff Peter Wemm has reportedly been doing. Yeah, a local media FS is pretty intimate with the VM system, especially in the getpages/putpages area (and, if supported as a direct interface instead of a layer on top of the getpages/putpages, bmap). But that intimacy should be formally abstract. It's a real lesson on where the rough edges are to port the entire framework to another OS. I *really* recommend that people serious about FS work try it; there's almost enough data in the O'Reilly Windows 95 IFS book to actually do the work for Windows 95. The VFS should be as free of FreeBSD'isms as the VM system should be (and is) free of i386'isms. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901051847.LAA10199>