[95] in arla-drinkers
Digital UNIX source merge
daemon@ATHENA.MIT.EDU (Johan Danielsson)
Sun Jul 12 11:52:09 1998
From arla-drinkers-request@sundance.stacken.kth.se Sun Jul 12 15:52:09 1998
Return-Path: <arla-drinkers-request@sundance.stacken.kth.se>
Delivered-To: arla-drinkers-mtg@bloom-picayune.mit.edu
Received: (qmail 7317 invoked from network); 12 Jul 1998 15:52:08 -0000
Received: from unknown (HELO sundance.stacken.kth.se) (130.237.234.41)
by bloom-picayune.mit.edu with SMTP; 12 Jul 1998 15:52:08 -0000
Received: from blubb.pdc.kth.se (blubb.pdc.kth.se [193.10.159.47])
by sundance.stacken.kth.se (8.8.8/8.8.8) with SMTP id RAA01241
for <arla-drinkers@stacken.kth.se>; Sun, 12 Jul 1998 17:47:09 +0200 (MET DST)
Received: from joda by blubb.pdc.kth.se with local (Exim 1.71 #3)
id 0yvOKn-0000H4-00; Sun, 12 Jul 1998 17:46:41 +0200
Sender: joda@pdc.kth.se
To: arla-drinkers@stacken.kth.se
Subject: Digital UNIX source merge
X-Emacs: 19.34
Mime-Version: 1.0 (generated by SEMI MIME-Edit 0.77)
Content-Type: text/plain; charset=US-ASCII
From: joda@pdc.kth.se (Johan Danielsson)
Date: 12 Jul 1998 17:46:40 +0200
Message-ID: <xofzpefjcm7.fsf@blubb.pdc.kth.se>
Lines: 59
X-Mailer: Gnus v5.6.9/Emacs 19.34
I finally tracked the `last' bug in the Digital UNIX port, so I
decided to merge the whole thing before things starts to break again.
The current status is that it almost works - you can do things, but
not very reliably, most vfs operations have not been tested, and some
of the locking is no doubt wrong. Use at own risk.
Since the OSF/1 VFS is based on BSD, everything went into the xfs/bsd
directory - but not without problems. There is currently an abundance
of ifdefs, some of these can probably be gotten rid of after some more
thought. Some of them are more difficult.
I decided to put everything in the bsd directory, since I think it
makes things more easily maintainable (having only one copy of
everything), and it is more easy to split the code (if one ever wants
to do that), than to merge it later on.
The following differences exist:
in general:
* OSF/1 uses struct nameidata, and BSD uses struct
componentname (they are mostly the same, though). This is
partially handled via horrible macros, but not always.
* the cred structure is slightly different
* the VOP_* `functions' are different
* you need to compile xfs/bsd with 'cc -std0'
xfs_dev.c:
* different select mechanism
* some BSD functions take a proc, where the OSF/1 ones do not
* the device installation stuff is different (no surprise)
xfs_node.c:
* getnewvnode is slightly different, should write a xfs_getnewvnode
wrapper
* vattr timestamps are different
xfs_syscalls.c:
* the syscall installtion code is different
xfs_vfsops.c:
* struct proc* or not - handled with a set of common
functions that are called by the BSD and OSF/1 specific
functions.
xfs_vnodeops.c:
* basically the same problem as in xfs_vfsops.c: BSD functiona take
a `struct vop_*_args' structure, OSF/1 functions take multiple
arguments (like SunOS4).
xfs_wrap.c:
* nothing in common
Some of these things can be handled with some creative use of macros
(like VOP_*); some files should perhanps be split in several files
(especially the vfsops/vnodeops wrapper functions, and the stuff in
xfs_wrap.c)
/Johan
