Darren Reed wrote:
I'd encourage the document to talk about how to do this.
For example, talk about what type of module is best here (character
device, STREAMS, etc), what they should do in entry points, exit points,
what interfaces they need to implement and so on.
Have you read the MAC-Type Plugin design document? That document
contains these details. The architectural documents that describe the
external interfaces are forthcoming shortly.
Maybe documenting how to use it like this is a seperate document, but if
I'm a 3rd party wanting to build a new tunneling device on top of this
frame work, just having this document doesn't appear to be what I want.
It talks a lot about changes and additions here and there, not so much
about what I need to do to develop a new MAC type.
That's not the aim of the IP Tunneling design document (is that the
document you're referring to?). The point of that document to provide
the design details of an IP tunneling driver and an IP tunneling
MAC-Type plugin, along with its administrative interfaces. The plugin
framework is described elsewhere (see the "Nemo MAC-Type Plugin
Architecture" section of the Clearview project page).
...
As I read it, you're introducing an API for you to use but nobody
else, so I ask what is the point of it being a documented API?
The API won't be documented. The design document contains these
details because it's part of the design of this project.
It is sounding to me like it is an implementation detail rather than
part of the design.
Hmm, maybe your definition of design isn't the same as mine, which is
fine. To me (actually, to most of the Solaris community), design
documents describe the internal design of an implementation, including
how implementation specific pieces work. This allows others to
understand the implementation and why particular implementation
decisions were taken.
Architecture is different. An architecture document (or functional
specification), describes external interfaces that other components of
the system or users use to interact with the feature. I think this is
what you're looking for, and we'll make those documents available as
they are written. These documents also have the level of detail that is
appropriate for the ARCs.
If the API in section 6 isn't part of the deliverables, why not just
remove the section?
Because it's part of the implementation, and the design document
describes the implementation.
I'd rather see more effort and focus put into external APIs that anyone
can use and build upon.
There is no external API. The only part of Nemo that is public is the
dladm(1M) command. Everything else is currently either project private
or consolidation private.
-Seb
_______________________________________________
networking-discuss mailing list
[email protected]
