Date: Sat, 22 Mar 1997 18:21:35 +0000 (GMT) From: Doug Rabson <dfr@nlsys.demon.co.uk> To: Terry Lambert <terry@lambert.org> Cc: Doug Rabson <dfr@render.com>, msmith@atrad.adelaide.edu.au, bde@zeta.org.au, dgy@rtd.com, hackers@freebsd.org, helbig@mx.ba-stuttgart.de Subject: Re: wd driver questions Message-ID: <Pine.BSF.3.95.970322175811.333C-100000@kipper.nlsystems.com> In-Reply-To: <199703211740.KAA15929@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 21 Mar 1997, Terry Lambert wrote: > > Interesting idea. Any chance of a design for such a system? > > It should take place in the vfs_init() (which doesn't have a macro op) > or the VFS_START() (which does). > > One problem here is that there is no corresponding "deinit"; it would > have to be defined. > > You would generate two classes of even initially: > > 1) VFSEVENT( type, fs) > > A VFS event of 'type' has occurred on the file system 'fs' > > 2) VOPEVENT( type, fs, vn) > > A vnode operation event of type 'type' has occurred on the > file system 'fs' affecting the file system vnode 'vn' > > This really goes back to defining the FS in terms of events and handling > of events... this needs to be done for generic support of soft updates > in all FS's, in any case. > > The "event management" would be a very generic subsystem in the > kernel, so an FS specific implementation is probably an error. The > lease code would be changed over to use "lease events" instead, and > the NFS would register to receive the events. If there were no NFS > server registration for lease events, then the events would be > ignored (all events for which there is not a handler are simply > ignored). For events with multiple handlers, all handlers are > called (two browser windows open on the same directory, and so on). > I supposed we could add an arbitrary "priority" field, and provide > the ability for a handler to "swallow" an event to make sure that it > does not propagate, but I'd rather not deal with inheritance issues > juset yet. Leasing is a bit different. The VOP_LEASE is used by the filesystem consumers to get read or write leases to the files before calling the other vops. I am not sure how this would fit into an event mechanism. > > Directory modification events would be pretty useful for the NFS > > server as well to extend the useful lifetime of NFS client cookies. > > The event would need to supply more information than just 'changed' > > since the seek values are still valid unless the directory was > > compacted. > > Yes; this is more like a "lock range decoelesce" for the modified > block. The client cookies in the "lock range" at the time of the > event would be invalidated. This would resolve the Sun NFSv3 > interoperability issue for the most part (there is still a potential > boundry condition, where BSD4.4 does directory truncation, and the > previous versions of UNIX and clone systems did not; but that's pretty > easy to deal with: if the cookie is past EOF, it's invalid). Life is slightly trickier for the NFS server since it doesn't keep track of the cookies which it has handed out. The client keeps track. It is hard for the server to distinguish between a cookie which is valid and one which was not affected by any recent directory modifications. Keeping track would involve too much complexity for very little gain, IMHO. It is still much easier to invalidate all the cookies on a compaction. What we can do is not invalidate the cookies when the directory is extended. That would help some clients. > > > If you are planning on doing any of this, I'm going to have to look > to see how much of my mount code changes made it in via Jeffrey Hsu; > the opportunity to modify the VFSOP operation is something that > merits *serious* design consideration... much of the original CSRG > work in the VFS integration was haphazard, IMO, and since we are no > longer under the legal pressures that caused them to have to cut > corners in the first place, we sould step back before diving in. I > would like to have input here, if you'll let me. > > [csrg deficiencies snipped] I will be doing at least some of this. I plan to spend the next several months working more or less full time on FreeBSD. It will make a nice change after the last two years hacking 3D graphics for Microsoft ;-). > > Actually, I expect the boot loader will have to be quite simple. To > > be practical, even with a 3 stage bootstrap the third stage will have > > to fit into 64k since it will need to use INT 13 for its disk access > > and our tools can't (and shouldn't) generate anything except tiny > > model programs. As a result, it will have severely truncated > > read-only file system support (see libsa from NetBSD). This is > > sufficient to load up the kernel. The boot will be discarded as soon > > as the kernel is entered. > > It's tempting to implement a protected mode VMM in the third stage boot; > have you seen: > > Protected Mode Software Architecture > _Tom Shandly_, MindShare, Inc. > Addison-Wesley Developers Press > ISBN 0-201-5447-X > > Yet? I haven't seen it; it sounds interesting. I will wander down to Foyles and see if I can find a copy. It may well be tempting to implement a VMM in the boot but I still think that it is overkill. The purpose of the boot code is to load the kernel and nothing else. If that can be done with a simple non-VMM bit of code then that is how it should be done. Boot code is hard to debug at the best of times so it should be kept small and simple IMHO. > > > > I was reading through libsa and our boot code yesterday and I believe > > that a 3 stage bootstrap for biosboot would be pretty easy. If the > > third stage was written using libsa then life would be much easier > > when writing an ELF loader. The filesystem and file descriptor > > support in libsa mimic normal syscalls making it possible to write and > > test the loader in userland before changing the bootstrap. > > Yes; I would like to see the objects move between the systems, actually, > which is why I was talking about a vnode-as-fd based kernel file I/O > subsystem with Mike the other day. Do you mean replacing the struct file with struct vnode? That seems worthwhile but is really best treated as a totally different piece of work. > > > > I for one find fiddling with the bootstrap a hair raising experience. > > I have some bad memories from the 386bsd days with bootstraps and > > disklabels. Shudder. > > Well, this is an issue for "device arrival" events (implied on a > "probe true" for a physical device) which are handled by a device > mapping layer handler. Used in conjunction with a devfs, this would > "magically" solve all the partition and diskslice and ... problems. > > I've discussed this before, but in case it wasn't obvious how the > algorithm could work, here's a 50,000 foo view of the idea: > > [more interesting stuff snipped] Again, I don't want to go too fast with this. Revamping disk partitioning and proper support for removable devices can come later. -- Doug Rabson Mail: dfr@nlsys.demon.co.uk Phone: +44 181 951 1891
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.970322175811.333C-100000>