Date: Sat, 16 May 1998 21:32:34 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: peter@netplex.com.au (Peter Wemm) Cc: bde@zeta.org.au, dyson@FreeBSD.ORG, current@FreeBSD.ORG, kkennawa@physics.adelaide.edu.au Subject: Re: libc corruption Message-ID: <199805162132.OAA12144@usr02.primenet.com> In-Reply-To: <199805161139.TAA02040@spinner.netplex.com.au> from "Peter Wemm" at May 16, 98 07:39:06 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Generating vnode_if.[ch] is another annoyance that I'd like to see > eradicated. The most obvious reason that this is generated data is to enforce the VOP interface semantics uniformly and universally. One of the original goals of the framework was to allow the operations to be proxied across anonymous boundries (ie: you don't know what you are handing the VOP to, but you have faith it will propagate normally). This is necessary for tunnelling VOPs between layers that understand their semantics through layers which don't. It's also necessary for proxying VOPs between machines (unlike NFS, unknown VOPs can be sent to another machine because the descriptor size is known), and for the proxying of VOPs to user space. A possible improvement would be to place VOPs in a linker-set instead of a statically defined structure. I considered this when I first made the changes to the initialization code to make the VFS compile and run correctly with zero filesystems (previously, it counted the VOPs FFS exported) during the Windows95 port. A related improvement would sort the vector to a known order, and eliminate the descriptor dereferences for non-proxied VFS consumer to VFS provider calls. This would reduce VFS layer overhead by the full descriptor re-assembly, lookup, and call overhead (~30-40 clock cycles on average for every VOP call). The main problem with this is dynamic extension and discard. One of the original "holy grails" that was smothered by the method used to integrate the framework into 4.4BSD is the ability to add new VOPs to a running system without needing a recompiled vnode_if.o. Even if you were to address the dynamic agregation issue (which I'm not about to trivialize), you would have bought little more than a change for the sake of change. This is because you will not have addressed the issue of how to add something to a linker-set in a statically linked kernel. One idea, which comes from ELF, is you could place the linker-set into an "allocate, copy, and discard" section. When the set was loaded, space for a copy would be allocated, the set would be copied, and the section that contained the non-extensible version of the set would be discarded. This has a number of compiler technology issues, namely the need to indirect set references through a pointer. One possible soloution would be to segment the kernel virtual address space and use segment selectors as part of the object address, allowing it to be relocated without the pointer dereference. I would like to see at least a non-extended VOP list in the vnode_if.[ch] continue to be generated, rather than agregated. Here's why: 1) If you agregate the list from the definitional location (ie: you glue it together from FS's the export the VOPs), then you open yourself up to desynchronization problems between FS's. Right now, that is not a problem. It will become more of a problem when allowing dynamic extension, but this can be mitigated by defining any additions in terms of the consumer, rather than the provider. Right now, there are few consumers, such as NFS and the system calls, and NFS, at least, is not going to be consuming new VOPs any time soon (though one could imagine a VOP for kernel-based globbing for use by an SMB or NCP server being very useful). 2) It is possible to post-process the vnode_if.src for other purposes. For example, a gateway device for proxying VOPs to user space so that you can debug FS stacking layers without causing a system crash. This is now possible, since vnodes can be managed by such a device instead of by the kernel's common routines, allowing the vnodes to be proxied, in the same way that nfsnodes proxy inodes from the remote system. 3) There's one place to look for the VOP semantics for all the standard, non-extended VOPs. 4) You would need to add a reference count to the linker-set construct per set entry, both to eliminate duplicate VOPs, and to allow unload of extensions, were they to occur. In closing, I think some changes should be made, but the most obvious reason for wanting the change you suggest is already handled by the explicit dependency rules (vnode_if.[ch] explicitly depend on the vnode_if.src). There's no chance of a libc/libkvm-like desynchronization causing similar problems. 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-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805162132.OAA12144>