9P2010
D1221753930
Aericvh
#
#MOTIVATION
#
#In my use of 9P within the Linux and IBM communities there have been
#several requests for extensions to better support Linux environments
#or features not currently a part of the protocol (locking, caching,
#batch operations, storage networking, etc.) As such, I'd like to
#work towards a specification of the protocol which can accomodate
#these extensions in as non-intrusive a way as possible (the
#counter-example being 9P2000.u which while negotiated ends up
#complicating clients and servers who wish to use it).
#
#BASICS
#
#The core protocol (size prefix, operation, tag) remains the same.
#The existing 9P2000 operations remain the same, 9P2000.u will be
#depricated by the new extension model. Extensions will exist in a
#complimentary namespace -- that is to say operation identifiers will
#not overlap with existing operations, and all extensions will use
#new operations as opposed to changes to existing operations.
#Alternate extension op-codes spaces may be negotiated by optional
#prefixes during Tversion negotiation -- but every effort will be
#made to keep operations within the existing namespace.
#
#The extensions are OPTIONAL, servers which don't wish to implement
#them (or any subset of them) simply returns Rerror -- well behaved
#clients will fall back to the core 9P2000 operations.
#
#OPERATION CODE RESERVATION
#
#To facilitate complimentary extensions, we'll use a wiki page
#[9P2010 Operations] to coordinate op-code reservation for specific
#extensions. It will be the definitive registration resource for the
#time being.
#