On the man pages, can we have "intro(3DLPI)" that enumerates
all of the functions within the scope of this section and gives
a brief, one line, summary of them, along with describing the
general architecture of the library?
Do the man pages need (or are they required) to make any statement
about MP-safety, given they are section 3?
Is it worth adding dlpi_fdopen() to cover situations where a
programmer wants to open something, push some STREAMS modules
and then get a dlpi_handle_t? Or does the model remain use
dlpi_open(), then dlpi_fd()? What about if I wanted to use
fd passing between two applications using this library?
For example, program with priviledges that opens devices
passing off fd's to a program that just communicates using
them.
There is no mention of any requirements regarding security
priviledges required for any of the operations. Is this
because there is none or because that should be documented
elsewhere?
For example, is NET_RAWACCESS required for dlpi_open()
to succeed with DLPI_RAW ?
For the project document...in the introduction, the following is written:
"The Clearview (PSARC/2005/132) project will be introducing new features that
require an extensible way to open DLPI links under different directories.
Currently, DLPI applications accessing data links assume DLPI filesystem
nodes are under /dev and use open() to directly access such DLPI links. With
Clearview's introduction of vanity naming, this assumption above will create
a problem because all vanity-named DLPI nodes will be placed under a /dev/net
directory. This libdlpi library proposes an interface, dlpi_open(), which
will provide an abstraction around this so that DLPI applications do not need
to know where the actual DLPI link is located in the filesystem."
Depending on your point of view, nodes under /dev/net are still
under /dev, just an extra directory removed. You should state
something like:
"With Clearview's vanity naming, an interface name could
be either under /dev or /dev/net. To relieve the programmer
from needing to search these directories, or possible other
places, for device nodes, we propose that the interface
dlpi_open() should be used." Or something like that.
The placement, in /dev or /dev/net is something that any
programmer could write code to deal with and isn't what I
would call an insurmountable issue that by itself requires
dlpi_open() to deal with.
"This issue gives us the opportunity to address a related problem, which is
that all DLPI-based applications currently implement their own DLPI utility
functions, and moreover, are intimately familiar with a variety of details
regarding the DLPI programming model. Indeed, in the ON consolidation alone,
there are nine overlapping- but-distinct sets of DLPI helper routines; dozens
more exist in unbundled and third-party products.
"ON currently includes a Project-Private libdlpi library (PSARC/2003/375),
which is sparsely used for a variety of reasons. This library proposes to
update that library's interfaces and promote them to Evolving so that they
may be used by all DLPI applications, both inside and outside of Sun. This
will provide additional benefit to our customers and ISV's, who will no
longer need to implement and test their own DLPI helper routines."
What percentage of the ON interfaces to DLPI will be replaced with
using libdlpi by this project? I suppose what I'd like to read
here is something like "we'll be converting X out of 9 to libdlpi"
as an indication that this development will be of use to such
applications.
_______________________________________________
networking-discuss mailing list
[email protected]
