On Nov 15, 2007, at 7:31 PM, Adam Leventhal wrote: > On Thu, Nov 15, 2007 at 06:43:07PM -0600, Spencer Shepler wrote: >> 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). > > Will an NFSv4.1 server be able to handle requests from a 4.0 client? > > Are you suggesting that there will be a probe called nfsv41:::op- > open-start > which has as its argument a OPEN41args structure? It wouldn't be > possible > to create some parameter which included the relevant information > from either > minor version?
Actually, the args/results have been extended in a way that it would appear as OPEN4args in both paths. So, yes, we could extend the proposed provided to accommodate NFSv4.1 with a method of communicating which minor version is being processed. Given the differences in the minor versions, I was thinking that a method that stood out more readily to the consumer of the provider would be helpful to alleviate confusion. If there is a minor version designator, that is fine with me for the moment. > >> 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. > > Yes, we're hoping that projects groups will realize the utility of > DTrace > providers and implement them as a part of their project. Certainly. Spencer _______________________________________________ dtrace-discuss mailing list [email protected]
