arla on NeXTSTEP3.3/Intel

[assar@stacken.kth.se]

> Hello,

Hi.

> I just compiled arla 0.21 on NeXTstep3.3/Intel (NS3.3). I had to make
> some changes, which are summarized below. Perhaps you could include
> them in the configure script?

> trying: ./configure --target=rhapsody
> ==> checking target system type... Invalid configuration `rhapsody': machine `rhapsody' not recognized
> 
> so I try instead:
> 
> ./configure --with-x=no
> we HAVE to disable X11, because we miss IceConnectionNumber() and other symbols

Doesn't configure itself recognize that there's no working X11?

> #changes to config.cache:
> #ac_cv_lib_ICE_IceConnectionNumber=${ac_cv_lib_ICE_IceConnectionNumber='no'}
> #
> #./configure
> 
> changes to include/config.h
> 
> #define MaxPathLen 255

Ah, you don't have a getcwd?  Added that to acconfig.h.

> #define HAVE_KRB_PRINCIPAL 1

Why did you need this?  According to the config.cache and config.log
below it manages to find the typedef?

> #define HAVE_SSIZE_T 1

And configure doesn't find ssize_t.  Do you have such a type?

> further changes:
> in file lib/editline/Makefile
> CC = cc -posix
> 
> 
> in file arlad/Makefile
> CC = cc -posix
> 
> 
> in file appl/Makefile
> CC = cc -posix

configure should check for that and add -posix now.

> Since my system was not recognized, it did not build the kernel stuff,
> only the user level stuff. arlad -t runs fine. But this is not really
> what I want (I want to mount an AFS file system). So I would be
> willing to try to port the kernel stuff, too.
> 
> Since NS3.3 should be similar to Rhapsody, I would like to start from
> there. Perhaps you or Alexandra could give me some hints or tips on
> how to proceed?

Yes, here follows some quite general porting advice/hints that I just
wrote.  I don't have access to any machine running NS3.3 so I doubt I
can help you very much other than by looking on and cheering.

----------------------------------------------------------------------
Porting xfs/arla to a new operating system

1. It helps to have source code for your operating system.

In theory, if stuff was documented well enough, you wouldn't need it.
In practice they never are so you find out interfaces and how stuff
work by reading the source code.  If you're unable to find source code
for your OS, try finding source for the closest match.  If your OS is
based on BSD, try the appropriate version of BSD, for example.

2. If you don't have source, try the second best things, the include
files in <sys/*.h>.

3. Be lazy.  Try to find out what other XFS/Arla port is most similar
to your OS and start with that code.

4. You need to figure out how a few things work in your kernel:

a. Loading/unloading kernel modules

That varies quite a lot but it's probably easy to figure out if you
have the source code for some other loadable module.  Sometimes you
can get the kernel to add your cdev, system call and file system
automatically but usually you have to write code in your `entry-point'
to add these to the appropriate tables.

b. adding a new character device driver

The kernel has a table of all known device drivers, ordered by major
number.  Some kernels have one for block device and one for character
device and some have a common one.  That entry usually consists of a
number of function pointers that perform the operations (open, close,
read, write, ...), and possible a name and some flags.  It could look
something like the following:

struct cdevsw {
	int (*d_open)();
	int (*d_close)();
	...
};

struct cdevsw cdevsw[];

These are then usually stored in a table `cdevsw' indexed by the major
device number.  If you're really lucky there's a new to get the kernel
to add your `struct cdevsw' to the global table when loading the
module or a function that does the addition for you.  If not, you'll
have to fallback on looking for a free slot in the table and putting
your struct cdevsw there.  In some cases, this is not stored in a
table but then there'll be a way of adding entries to the new data
structure so you don't need to worry about it.

c. adding a new system call

This is quite similar to adding a new cdev but the table is usually
called `sysent' instead.

d. adding a new file system

Once again, quite similar in principle. The names of the structures
tend to vary quite a lot more.

e. finding out how the VFS/Vnode switch works

The structure that you added in (d) contains function pointers for all
of the file system operations.  You need to figure out what operations
you need to implement (usually at least mount, unmount, root, sync,
and statfs).

The operations that are performed on files are vnode operations
(usually stored in a struct vnodeops), and you need to figure which of
these you need and how they should work.  Also, which is not as
explicit, how vnodes are supposed to be allocated and freed and such.

5. Suggested plan of action

a. Once you have done (4a), start by writing a minimal hello-world
module and make sure you can load and unload it properly.

b. Then add a device driver to the module which dummy functions and
very that works.

c. Try to fit the device driver functions in xfs_dev.c into the device
driver.

c. Do a dummy module with a system call and very that you can call it.

d. Start trying to add enough of the vfs/vnode operations from
xfs_vfsops.c and xfs_vnodeops.c so that you can build it.

e. Debug it.
----------------------------------------------------------------------

Don't hesitate to ask if you have more questions.

/assar