Date: 21 Mar 1997 11:13:49 +0000 From: Doug Rabson <dfr@render.com> To: Terry Lambert <terry@lambert.org> Cc: msmith@atrad.adelaide.edu.au (Michael Smith), bde@zeta.org.au, dgy@rtd.com, hackers@FreeBSD.ORG, helbig@MX.BA-Stuttgart.De Subject: Re: wd driver questions Message-ID: <sen2rxsdjm.fsf@minnow.render.com> In-Reply-To: Terry Lambert's message of Thu, 20 Mar 1997 11:14:04 -0700 (MST) References: <199703201814.LAA13973@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert <terry@lambert.org> writes: > > > That's the one. There's also quite a lot of code whose behaviour depends > > on various other options, but it would be practical in the short term > > to just compile several times with the sensible combinations of the > > various options and produce different modules. (I am thinking here > > fe. of NFS_NOSERVER) > > The NFS_NOSERVER code changes the way the lease VOP's operate, not > because the code should be condition, but because the code is badly > integrated. > > The registration of lease management mechanisms should take place > for all VFS consumers, not just NFS. This is a generic issue with > not being able to register a set of event callback entry points for > a module. The *real* problem here is that the NFS server wants to > register event handlers, but the server and the client code are in > the same module space. This is really a source organization issue. Interesting idea. Any chance of a design for such a system? > > I could see a number of useful events that a VFS consumer at the > system call level would want to register. For instance, directory > modification events would probably be useful for a file browser > application to monitor. 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. > [snip] > > > > You are still not listening 8); I have just said "when you discover you > > need the blocks, you can no longer read them because your load source > > has gone." This is an issue for the period from when control is > > transferred to the loaded kernel from the linker until a filesystem is > > mounted, and thus all the code that could possibly be required over > > that interval must be present. > > Heh. You aren't listening to me... you don't get rid of the boot-loader > code. If you don't get rid of it, you can still use it. > > It's like the BIOS based boot being able to use the INT 13 redirector > supplied by OnTrack, when you boot from an OnTrack drive. As long as > you don't override it, it's still there. 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. 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. 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. -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 These are not the opinions of Microsoft. FAX: +44 171 734 6426
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?sen2rxsdjm.fsf>