Peter Memishian wrote:
> 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.
Is there any chance of us being able to implement something as part
of this project rather than wait for a "call" and have to react ?
I suppose there's the question of what should it look like, if
we don't yet have something to use it, to complicate matters :-/
> 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.
Hmm, two problems.
First, /etc/security/device_policy does not always match the
list of network interfaces available. My desktop has nge0
(from SUNWnge) but device_policy does not. This is quite
possibly a bug in packaging and/or driver enforcement.
I suppose this issue has nothing to do with this library.
Second, dlpi_open() has three different open modes and
device_policy only appears to cover "raw access". This
tends to suggest that only 1 of the 3 modes of opening
a device with dlpi_open() would be covered here.
If dlpi_open() isn't the right place to mention that this
(or some other) privilege is requried, where would be?
Do we put it in the device man page or somewhere else?
For example, I went to try and find some document that
would tell me what bge requires in S10U2:
1) there's no man page for device_policy;
2) bge(7d) doesn't say anything
3) dlpi(7d) doesn't say anything
4) gld(7d) doesn't say anything
> 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".
Some replacement of "which" with "that" would also be good.
> 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.
Yup and this is a good thing. I think it is just the way it is
expressed: it doesn't focus enough on move to having an abstraction
layer being a good thing. Maybe I'm just expecting more fluff words :)
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
