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? > 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. Adam -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl _______________________________________________ dtrace-discuss mailing list [email protected]
