> 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?
Yes, the policy is to always do these for public libraries. However, it seemed unnecessary for the PSARC review since the case materials cover this background in more detail. > Do the man pages need (or are they required) to make any statement > about MP-safety, given they are section 3? Stuff like that and interface stability is typically added as part of the review cycle with the manpage team. Since it's clear from other ARC materials, there's no reason to bloat the proposed manpages with it for ARC review. > 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()? Right, that's the model. As covered in the materials, one of the goals of the library is to not expose the DL_UNATTACHED state, since it complicates the programming model and is generally useless. > 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. We're not aware of any unrelated applications that pass DLPI descriptors. If the need arises, a routine can be added to make it possible to convert a file descriptor to a DLPI handle. > 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? Any open of a DLPI link is dictated by the underlying permissions associated with the device node and /etc/security/device_policy. It could be stated in dlpi_open(), though it feels a bit odd there. > 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. OK, we'll add the word "directly" before "under /dev". > 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. Sure, but the motivation for this library fell out of not forcing developers to dump more fiddly DLPI logic into their codebase, and further, to reduce the likelihood that they would have to modify their code again in the future. > What percentage of the ON interfaces to DLPI will be replaced with > using libdlpi by this project? All. -- meem _______________________________________________ networking-discuss mailing list [email protected]
