On Nov 15, 2007, at 4:27 PM, Adam Leventhal wrote: >>>> Given that these protocol mechanisms will exist at client and >>>> server, it would be helpful to have a naming mechanism that >>>> differentiated this fact. >>> >>> Perhaps the module name could be used as the differentiator? >>> >>> nfsv4:client::op-<op> >>> nfsv4:server::op-<op> >> >> No preference; just needs to be present. > > The plan is to have a different provider; either nfsv4c or > nfsv4client or > something.
Great. > >>>> I also assume that when NFSv4.1 >>>> is introduced that the provider will be expanded to something >>>> like: >>>> >>>> nfsv41:::op-access-start ACCESS4args * >>>> ... >>> >>> Does 4.1 differ so much from 4 that the provider name itself must >>> differ? >> >> That's funny. Yes. > > How funny is it? Will we want to support both the nfsv4 and nfsv41 > providers? > Will the probes overlap in a way that would create incompatibilities? Funny == flippant, in the sense that I would have expected Nico to know some of the details and was poking him a little on the issue (Hi, Nico). as for the details.. NFSv4.1 is introducing a set of new operations to inflict the new set of features within the protocol. There is a mix of optional and mandatory to implement operations and corresponding args/results. That isn't going to be a problem. The real issues are that there are 4-5 operations that have been designated as mandatory-not-to-implement; meaning that they may appear as defined in the RPC language but are never to be used -- the vestiges of NFSv4.0. That isn't too much of a problem either. The larger issue is that there are a couple of arguments (OPEN mainly) that have been extended through the NFSv4 minor version rules to include additional parameters in effect. This means that an NFSv4 and NFSv4.1 provider should not share the argument definition. I don't see that as much of a problem either if the providers were per minor version (e.g. NFSv4.0 and NFSv4.1). In summary, the proposal is fine with me as long as we have an expectation that a new provider (similar in size and complexity) will be in place for NFSv4.1. Spencer _______________________________________________ dtrace-discuss mailing list [email protected]
