Darren J Moffat writes: > Dale Ghent wrote: > > Recently, over in OpenAFS land, a issue arose with the OpenAFS code > > failing to build on snv due to a side effect of the August-ish > > introduction of NFS RDMA as a part of PSARC 2007/347. > > > > In OpenAFS code, we have a struct we use called "conn". OpenAFS sucks > > in RPC and NFS-related header files as part of its AFS->NFS translator > > functionality. With the introduction of NFS RDMA, its attendant header > > file, rpc_rdma.h, introduces a struct of the same name[1]. Hence the > > build failure with the expected redefinition errors. > > > > I'm not sure what the general policy is regarding namespace of such > > things, and it could be that the NFS RDMA code is compliant in such > > regard... but I can't help but to think that giving that a name of > > "conn" is a bit too generic? Would "rdma_conn" be more appropriate? > > Ignoring any standards issues I'd personally say that both the OpenAFS > and NFS RDMA codebases are partly to blame. "conn" is just too generic > a name for a type/variable. Both codebases IMO should have used an > appropriate prefix on this eg: afs_conn, rdma_conn. I'm a little > surprised that the RDMA code didn't have a prefix on that given that > other types declared in that same header do.
Indeed. But as the boundary for the namespace in question is the ON consolidation (those aren't public interfaces that AFS is using), I think it's possible to draw a slightly sharper distinction. Filing an RFE asking for NFS RDMA to stop camping on that too-generic symbol sounds like a fine thing to me, but it's hard to say that it's completely wrong. -- James Carlson, Solaris Networking <[email protected]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
