>
> This should get you started, Bill.
>
> Have a look in linux/include/linux/xfs_fs.h to see how the
> already-ported IRIX/XFS syssgi calls have been mapped to ioctl
> calls under Linux/XFS. I've marked the (numerous) places where
> porting work needs to be done with "TODO" in a comment, and
> commented out the offending code.
>
> Obviously, this code is not fully functional at the moment.
>
> cheers.
>
>
> Modid: 2.4.0-test1-xfs:slinx:67047a
> Date: Mon Jul 17 23:52:42 PDT 2000
> Workarea: snort:/build4/nathans/2.4.0-test1-xfs
> Author: nathans
>
> The following file(s) were checked into:
> bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs
>
> cmd/xfs/fsr/Makefile - 1.1
> cmd/xfs/fsr/fsr_xfs.c - 1.1
> cmd/xfs/fsr/jdm.c - 1.1
> cmd/xfs/fsr/jdm.h - 1.1
> - Initial version - compiles on Linux, nothing more.
>
Sorry to be late to pipe in.... This direction seems fine to me..
I'm about half-way through getting extended attributes to work,
have been able to "set", "get" & "list" a single extended attribute,
having some minor "endian" trouble in xfs_da_dobuf...
I'm implementing the extended attribute stuff via syscalls, as in
Irix, the logic being that they are all "pathname" style interfaces,
and it's necessary to be able to "sniff" the attributes before
opening the file, especially so for "special devices"..
At the same time, as a backup position, I'm toying with adding
parallel ioctl interfaces. Anybody have opinions on this? It
would only be necessary if there was "significant" resistance to
the syscall approach.
-Ted
|