chris@mimsy.UUCP (Chris Torek) (09/24/89)
In article <11148@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >[SVR4]'s memory management, like SunOS's, is entirely different. I.e., the same as that in SunOS. >Its character I/O system is entirely different. I.e., the same as that in SunOS (but this time because the STREAMS code [oh, how I hate all caps] in SunOS is adapted from SV, rather than vice versa.) >Its general filesystem support is entirely different Of course, everyone will use the 4.2 file system unless unwilling to expend the time to convert. Although the RFS internals differ from the vnode internals, the two are essentially the same (modulo SunOS's ridiculous insistence that the local file system be stateless). SunOS will no doubt support the SV file system, so when SVR4 is out and SunOS X.Y is out (for whatever X and Y are): the same, effectively, as SunOS. >... Its network base is entirely different, although some of the >"r-commands" may have been adapted from BSD versions. Well, there is no accounting for taste. >And in general it makes the current BSD release look sick. As I see it, the only major improvements over BSD are: the POSIX terminal driver (already in BSD, although who knows when it will be out); the file system switch (vnodes are also already in BSD, although the NFS is a wee bit raw as yet, and Jacobson's TCP NFS is not in there [TCP NFS is faster than UDP NFS, given a well-coded TCP]); and the new VM system. Of course, the VM system is based upon a design done at Berkeley, and modified a bit at Sun. At any rate, work is proceeding on POSIX- and ANSI-fication of BSD, although some of it hinges on installing gcc everywhere (I am a bit reluctant to make gcc our standard C compiler, myself---probably just residual paranoia from observing early gcc releases to do very peculiar things.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (09/26/89)
In article <19776@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: | At any rate, work is proceeding on POSIX- and ANSI-fication of BSD, | although some of it hinges on installing gcc everywhere (I am a bit | reluctant to make gcc our standard C compiler, myself---probably just | residual paranoia from observing early gcc releases to do very peculiar | things.) Another reason that keeps some sites from using gcc is that if you link using their object library you are bound by the copyleft to make the source of your program available to the public. You can use the gcc compiler, but when you bind in the FSF library you have to play by their rules. This is a major concern when you have software which reflects the insights gained from millions of dollars in (physical) research and would like to avoid having to share with you competitors... -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
guy@auspex.auspex.com (Guy Harris) (09/26/89)
>>Its general filesystem support is entirely different > >Of course, everyone will use the 4.2 file system unless unwilling to >expend the time to convert. Although the RFS internals differ from the >vnode internals, the two are essentially the same Uh, what is RFS here? As of when I last had anything to do with S5R4, AT&T's RFS was to be implemented in S5R4 basically as a file system type under the S5R4 VFS mechanism. By "RFS" are you referring here to some 4.4BSD equivalent to VFS? If so, whoever named it might want to consider choosing a different name, to avoid confusion. >(modulo SunOS's ridiculous insistence that the local file system be >stateless). To what are you referring here? >>... Its network base is entirely different, although some of the >>"r-commands" may have been adapted from BSD versions. > >Well, there is no accounting for taste. Well, I don't know what "entirely different" means here. The networking code is based on streams and TLI, but: 1) there should be a sockets interface to TCP and UDP, at least, in S5R4; 2) the TCP/UDP/IP implementation should at least be derived from a 4.3-tahoe-vintage BSD implementation. >Of course, the VM system is based upon a design done at >Berkeley, and modified a bit at Sun. Are you saying that the SunOS 4.0 VM design was done at Berkeley, and just "modified a bit" at Sun?
chris@mimsy.UUCP (Chris Torek) (09/26/89)
(`>>' comments are mine) In article <2499@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >Uh, what is RFS here? As of when I last had anything to do with S5R4, >AT&T's RFS was to be implemented in S5R4 basically as a file system type under >the S5R4 VFS mechanism. Oh. This I do not really understand, since the RFS mechanisms are pretty much equivalent to the VFS mechanisms, except that instead of vnode->vn_op(vnode, arg1, arg2) one writes (*fsswitch[inode.fstype])(inode, arg1, arg2) I.e., other than the vnode/inode/gnode/foonode differences found between all the different `virtual remote generic network filesystem interface definition specification ...' er, well, whatever, systems. I had supposed that VR4 was going to stick with RFS-style mechanisms. >>(modulo SunOS's ridiculous insistence that the local file system be >>stateless). >To what are you referring here? Things that got cleaned up since the code I looked at, perhaps? The VFS UFS code I saw (whenever it was that I was looking at it) did not bother locking parent directories in vfs_lookup, so that when it came time to write new entries, the state may have changed, etc. I.e., one could have a sequence where an `O_CREAT|O_EXCL' open could write over an existing file. >>Of course, the VM system is based upon a design done at >>Berkeley, and modified a bit at Sun. >Are you saying that the SunOS 4.0 VM design was done at Berkeley, and >just "modified a bit" at Sun? Well, actually, there was a fair bit of interaction (and not just from Sun), but the basic design (mmap+mummap, protection, mapped files) comes almost straight from 4.2BSD (where it came almost straight from Multics). There are areas where Sun and Berkeley might not agree (e.g., mmap for semaphored memory), but the user/system interface will at least be very similar. (The implementations are likely to be quite different.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
mre@pyrps5 (Mike Eisler) (09/26/89)
In article <chris@mimsy.UUCP> writes: >Oh. This I do not really understand, since the RFS mechanisms are pretty >much equivalent to the VFS mechanisms, except that instead of > > vnode->vn_op(vnode, arg1, arg2) > >one writes > > (*fsswitch[inode.fstype])(inode, arg1, arg2) RFS - remote file sharing. A distributed network file system from AT&T FSS - File System Switch. In SVR3 an inode based file system switching mechanism. In SVR4, a vnode based file system switching mechanism. VFS - Virtual File System. In SunOS 2.0 to 4.x, as well as NFSSRC 2.0 to 4.0, a vnode based file system switching mechanism. As Sun as gone on record as saying they will support SVR4, one can expect the VFS to be superceded in future versions of SunOS by SVR4's FSS. The fsswitch[] directives Chris is describing represent SVR3's FSS. RFS is (nominally) an entry in SVR3's FSS, just at the System V file system (from AT&T), and NFS (from Lachman and others) are entries (not nominally) of the FSS. To understand why RFS is nominally an entry of the FSS, see Chartock's paper in Summer USENIX (Phoenix) '87. -Mike Eisler mre@pyramid.com
guy@auspex.auspex.com (Guy Harris) (09/28/89)
>Oh. This I do not really understand, since the RFS mechanisms are pretty >much equivalent to the VFS mechanisms, except that instead of > > vnode->vn_op(vnode, arg1, arg2) > >one writes > > (*fsswitch[inode.fstype])(inode, arg1, arg2) OK. You used "RFS" instead of "FSS" ("File System Switch"), just as some people refer to "NFS" when they really want to refer to VFS (the "Virtual File System" mechanism). Actually, in S5R3, RFS doesn't fully *use* the FSS mechanism - it still does a lot of things by capturing system calls directly. I think the intent is to put it mostly, if not entirely, under VFS for S5R4. >I.e., other than the vnode/inode/gnode/foonode differences found between >all the different `virtual remote generic network filesystem interface >definition specification ...' er, well, whatever, systems. I had supposed >that VR4 was going to stick with RFS-style mechanisms. Nope. S5R4 is switching to a VFS mechanism. >>Are you saying that the SunOS 4.0 VM design was done at Berkeley, and >>just "modified a bit" at Sun? > >Well, actually, there was a fair bit of interaction (and not just from >Sun), but the basic design (mmap+mummap, protection, mapped files) comes >almost straight from 4.2BSD (where it came almost straight from Multics). >There are areas where Sun and Berkeley might not agree (e.g., mmap >for semaphored memory), "Semaphored memory"? >but the user/system interface will at least be very similar. (The >implementations are likely to be quite different.) OK, you were referring to the *interface* design, not the *implementation* design; the latter was done at Sun, while the former is derived from the stuff described in the 4.2BSD paper, but not implemented in 4.xBSD (except perhaps trivially for some device drivers, just as was the case in SunOS prior to 4.0.)
chris@mimsy.UUCP (Chris Torek) (09/28/89)
>>... semaphored memory In article <2508@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >"Semaphored memory"? Oops, typo: I meant `semaphore memory'. The mmap() call in 4.4BSD will (assuming it gets implemented!) require a special flag (which might well be a pseudo-flag, i.e., 0) in order to map for use as semaphores. As Kirk put it, I believe that shared memory is an interesting IPC mechanism only if semaphores can be mostly done without system calls, and hence must be provided for in the interface. HASSEMAPHORE provides this hook; some multiprocessors require that semaphores be in uncached memory or only in semaphore registers. This flag would allow the system to set up such uncached regions when it knew that semaphores were going to be used. For machines with hardware semaphore registers, the flag would cause the mmap with HASSEMAPHORE set to fail on anything other than a mapping of the special device associated with those registers. Presumably the interface to semaphores used for shared memory will be hidden in a library routine. >OK, you were referring to the *interface* design ... Quite. >[which] is derived from the stuff described in the 4.2BSD paper, but not >implemented in 4.xBSD (except perhaps trivially for some device drivers, >just as was the case in SunOS prior to 4.0.) (Not even in any drivers.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris