From owner-freebsd-fs Fri Aug 30 00:09:48 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA15473 for fs-outgoing; Fri, 30 Aug 1996 00:09:48 -0700 (PDT) Received: from obelix.cica.es (obelix.cica.es [150.214.1.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA15452 for ; Fri, 30 Aug 1996 00:09:44 -0700 (PDT) Received: (from amora@localhost) by obelix.cica.es (8.7.5/8.7.3) id JAA02749; Fri, 30 Aug 1996 09:05:52 +0200 (GMT-2:00) From: "Jesus A. Mora Marin" Message-Id: <199608300705.JAA02749@obelix.cica.es> Subject: Re: s5 filesys implementation? To: terry@lambert.org (Terry Lambert) Date: Fri, 30 Aug 1996 09:05:51 +0200 (MET) Cc: dyson@iquest.net, jkh@time.cdrom.com, freebsd-fs@freebsd.org In-Reply-To: <199608271612.JAA24806@phaeton.artisoft.com> from "Terry Lambert" at Aug 27, 96 09:12:58 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'll try to answer to everybody with this. Terry Lambert said: > This is onmy list of "to do" items. I was an engineer for Novell/USG > (USL) who worked on, among other things, kernel FS code. Glad to meet you, Terry. I didn't mean to jeopardize anyone's 'to-do' list :) > If you are planning on working on FS code in the very near future, > then I'd say go ahead. Otherwise, I hope the lanscape will be changing > pretty radically pretty soon -- if you have done enough FS work that > you can abstract framework components from implementation, then you > should be pretty safe for any long term projects that you want to > pursue. > > You may want to consider holding off until the Lite2 integration has > been completed; since it changes some of the architecture. I don't > think it;s safe to assume that the changes from that direction are > done either. > > Your best bet would be to get in contact with David Greenman or John > Dyson, since they make architectural decisions, and the FS is one > place that will be hit (one way or the other) by almost all > architectural changes. Argh! Can you please stop messing a while? I can imagine the picture: a red light starts to blink at the FreeBSD Hackers Command Center. "Hey! Jesus has got a minimal understanding about proc scheduling. Let's change all the stuff right now!" :) Now serious. My main objective with this project is educational. I've been studying the implementation of VFS in SysVR4, and was appealed by its design. Just for fun, I took the FreeBSD code for this subsystem and saw it's organized in a very similar way, if not identical. Furthermore, this code seemed rather clear to me, so I have decided to try a practical approach. I know that support for sysv fs is not a very useful thing, but it's not implemented yet and I've been living with it for many years. sysv fs is not a very sophisticated one and has a very simple organization, so fs-dependent code would not be very painful to write. Also, inode struct is almost identical to that of ffs, and no anaesthetical tricks are needed as those required when you deal with msdosfs, so the implementation should be clean. For some time, I was considering simply to port the code in Linux, but I was not aware of how it performs, nor that its integration in FreeBSD is a straightforward task. So I've decided to start from scratch, but I don't discard to "borrow" some ideas from the Linux code -with its author's consent, of course-. Now, an overview of what I plan is: *) Further learning of the vfs subsystem in FreeBSD, and its interface with fs-dependent code. This phase does not necessarily precedes the others, but overlaps them (crashes teach a lot :) 1) Implementation of fs type dependent VFS ops, ie s5fs_mount(), s5fs_sync(), and so on. I should begin this right now. I'd start working with SCO Unix SVR3 filesys in diskettes only. If I become confident enough, I could install an old SCO Unix version in my HD. I think that giving support for xenix filesystems could be considered, if I find any diskette to work with. User-level mount_s5 command must be avaible at this point. Funny, you can (u)mount it, stat it, but no more :) Anyway, I guess this stage won't take more than a few days. 2) Implementation of fs type dependent vnode ops, (s5fs_open/close, _read/write, ...). I must consider which functions to implement and which ones are nonsensical in a non-primary filesystem type. Suggestions appreciated. 3) Writing additional user-level commands: fsck_s5, mkfs_s5, fsdb_s5? 4) Last but not least: trying to write a doc describing the design and internals of FreeBSD VFS subsystem, and my own experiences with s5 support implementation. It could be a potential contribution to the Documentation Project, that is, given it worths its space in disk and if some masochist volunteer translates my weird "English" into a correct one. Should I get just this one, I will be happy. You can see, I am not a Unix guru, nor a hacker, but I will do my best this time. Also, I hope you will lend me a hand when needed -I'll get stuck, you can bet-. BTW, John Dyson : > I suggest working with the Aug snapshot or later. What's the most recent snapshot stable enough? I run 2.2-960326SNAP at job and had no problems with it. At home, I run 2.1-RELEASE, and received 2.1.5-RELEASE yesterday, but I'm considering to jump to a 2.2-SNAP. Please info and I'll order. So please, hints? suggestions? discouraging comments? funds (cash only please)? Jesus A. Mora amora@obelix.cica.es