It turns out namei_ops actually is better than I had feared because it sets up
afs_open to be OS specific, whereas other modules
#define it to be "open" or "open64" regardless of OS.
There are only four (possibly benign) miscasts right now and I'll submit a fix
for them shortly.
However I'd like to do something about the use of afs_open in this module since
1) it's confusing
2) it leads to ugly code. At various places we see
afs_open() ... close()
afs_open() ... nt_close()
afs_open() ... OS_CLOSE()
I want to go through this module and replace afs_open &co with OS_OPEN since
all the generated descriptors find their way into other
OS_XXXX functions by way of the FDH_XXX macros. But I'm testing the water here
first.
Further, Simon said:
> This would entail replacing all use of the int family with the FD_t family.
> In my view, this would be best acheived by adding a platform independent
> I/O framework to our nascent opr portability library.
This sounds to me like the right long term strategy. As Jeff alluded I have do
something like this for vol but I don't have the
hours to the full monty right now and so I had intended taking a short cut by
borrowing the existing platform independent framework
in Ihandle (OS_XXX).
However it strikes me that I might be able to make someone's life easier in the
future by using perhaps another level of macros -
something which would be defined to OS_XXX for now, but could be recast to be
something else in the future. I'm not sure that this
will gain much since the use of OS_XXX is pretty limited, but it is better to
do the work now than try to unpick "original use of
OS_XXX" and "Rod's extended use of OS_XXX" at a future date.
Comments?
Rod
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
