On Fri, 21 Jan 2011 08:44:37 -0000 "Rod Widdowson" <r...@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 adea...@sinenomine.net _______________________________________________ OpenAFS-devel mailing list OpenAFS-devel@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-devel
