[OpenAFS-devel] Re: Avoid mixed use of Win32/CRTL in the servers

Andrew Deason adeason@sinenomine.net
Fri, 21 Jan 2011 10:06:33 -0600


On Fri, 21 Jan 2011 08:44:37 -0000
"Rod Widdowson" <rdw@steadingsoftware.com> wrote:

> What is the expectation about afs_open and friends - such as afs_stat
> which is used in some places to mean both the function and the
> struct..

I think afs_stat is the only one used like that; just because the
function is stat/stat64 and the struct is 'struct stat'/'struct stat64'.
I don't expect there was a whole lot of design consideration given when
these macros were created; you can tell since they were just copied
around.

> I would like to leave afs_open defined as "use the c run time library"
> and reserve it logging and so forth;  then use OS_XXX for [meta]data
> IO.  Converting logging to Win32 CamelCase code would be tedious to
> say the least and would not affect the issues that we have between
> mixing io between the c run time library and the windows one.

Well, eventually it would be nice not to have two different
abstractions, unless there's a reason we need a different one. But for
now, sure, no argument.

> Equally I'm slightly nervous about wholesale conversion of afs_open to
> OS_OPEN.  Maybe it safest to just do it in the paths which are
> compiled for the Windows build?

It should be identical to afs_open on unix platforms (open64 if we have
O_LARGEFILE, open otherwise). But you could split it into commits that
change it for NT40 only, and everywhere else, if you wanted.

> Also, for my information, why are OS_XXXX defined in ihandles.h?
> historical?

It's the lowest level of the ihandle package I/O abstractions. It's only
used in ihandle right now, but it's identical to the other existing
abstraction and it seems like exactly what we want here, so...

-- 
Andrew Deason
adeason@sinenomine.net