[OpenAFS-devel] File Descriptor use in the vol package

[Rod Widdowson]

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