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

[Andrew Deason]

On Fri, 28 Jan 2011 16:47:56 -0000
"Rod Widdowson" <rdw@steadingsoftware.com> wrote:

> 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?

The OS_ calls are the same as the afs_ calls except where the afs_ calls
are broken, as I understand it. I'm not sure I see any value in making
the distinction in going to a new non-OS_ non-afs_ series of macros,
since it really seems to me like we're going to need to go through all
of them and see what behavior we want from them, anyway. (If some new
abstraction has different behavior.) It'd be helpful for auditing if
they're all the same, so they're easy to find.

And adding a new abstraction that's just for "the things Rod changed" or
"the things changed in Jan/Feb 2011" is just confusing. We already have
afs_* and OS_* which appear to be exactly the same in intent, and it's
already confusing!

Oh, and technically, it's easy to see what the original uses of OS_*
were, because they are all confined to ihandle.{c,h}

Another example is the Unix CM, which has or had (IIRC) 3 or 4 different
abstractions for grabbing a reference to a vnode. But all of the
abstractions #define'd to effectively the same thing, which makes it
really unclear what their purpose was, or why you would want to use one
over another. I'd like to avoid that.

-- 
Andrew Deason
adeason@sinenomine.net