On Mon, Mar 9, 2009 at 10:17 AM, Felix Frank <[email protected]> wrote: > >> The patch provided in 124130 broke the Windows platform because it >> removed exported symbols names from the library. As I indicated back >> in January, if the functionality is going to be renamed but is identical >> to the old wire protocol, then stub functions need to be created for >> the old names. Those names can call the new names or return an error. >> It doesn't matter which. > > I wasn't aware that such things could happen. So do I see this right? > It's either > - create new RPCs and let the old one's in place or > - create new Stubs with the old names and replace the old ones > > Is that so?
yes. given the same functionality and an assumption it stay so, doing the latter seems perfectly > >> There is the possibility that MPG and DESY will have to upgrade in any >> case. As part of OSD the behavior of the AFSFetchStatus SyncCounter was >> modified. Unfortunately, OSD is not the only project that has decided >> to modify this field. Sorting out who is going win the use of the >> SyncCounter is not up to OpenAFS. That needs to be decided by the >> members of the afs3-stds mailing list. Depending on how it gets >> decided someone is going to lose or perhaps everyone will lose. By >> losing I mean that their organization will be forced to upgrade. > > Good point. Maybe we should strive to at least solve this conflict. After > all, OpenAFS+OSD uses only a few bits for the protocol. As far as I can > tell, the last volume update requires a whole 32-bit integer... it uses it for a timestamp, so that's true. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
