Jeffrey Altman wrote: > Felix Frank wrote: > >> Jeffreys concerns are >> a) broken library interface exports >> b) possibly modified behaviour >> >> Hartmut's responses were concerning (a) that the symbols in question were >> only bound by applications that called the MR-AFS specific RPC that >> is the issue here. >> The only applications that did so were >> - MR-AFS's fs >> -> obsolete >> -> has been used only by Ken Hornstein, Uni Chemnitz and Garching >> -> Garching had been the only MR-AFS site for years and now there >> are none left >> - MR-AFS's cache manager >> -> not linked against libraries, but built with complete source instead > > 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.
To avoid this problem I think we could change back the names of this RPC to ResidencyCmd. In the Unix/Linux environment the name doesn't matter at all as long as the kernel module is compiled completely from source code without using any libraries. So I opt for renaming FsCmd back to the former ResidencyCmd > >> Concerning (b), all original behaviour is retained, all modifications are >> mere additions that don't break compatibility. The (former) ResidencyCmd >> has always had an extendable design. > > That is true for the "fs" functionality included in this patch. > >> While retrofitting OpenAFS+OSD to using the legacy names is at all >> possible according to Hartmut, it implies (unnecessary?) efforts as the >> existing cells at MPG and DESY would need to be "upgraded" completely. > > 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. The best thing would be to create a new struct AFSFetchStatus64 with an afs_uint64 field for the file size and some more fields (also spares) for the purpose we and obviously also other groups are abusing the SyncCounter. Then, of course, some new RPCs are needed to replace in the long run the current RPCs which use AFSFetchStatus. This would also give us the opportunity to get rid of some old stuff e.g. AFSVolSync which is provided by the cache manager for a number of RPCs, but nowhere examined at all. Doing this, however, we must make sure not to get an overlap in the RPC numbers! When I modified the code for MR-AFS and later for OpenAFS+OSD I let a gap between the last RPC-number used by OpenAFS and the first one I used. This gap has shrunk to to eight (65543-65550) in the meantime. Hartmut > > Jeffrey Altman > > _______________________________________________ > OpenAFS-devel mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-devel
smime.p7s
Description: S/MIME Cryptographic Signature
