On Tue, Mar 31, 2009 at 12:13 AM, James Carlson <james.d.carlson at sun.com>
wrote:
> Cyril Plisko writes:
>> On Fri, Mar 20, 2009 at 10:32 PM, Cyril Plisko
>> <cyril.plisko at mountall.com> wrote:
>> > Another way to resolve it would be to try dlopen() on libpciaccess,
>> > but that would change the behavior of prtconf -dv in non-obvious way.
>> > Anyway, feedback is most welcome.
>
> That doesn't fix the problem. ?dlopen() and "ld -l" are the same
> thing, at least in terms of interface dependency.
The only difference I see is that with dlopen() I can ignore the
missing library and continue executing (possible reducing
functionality), while with "ld -l" the ld.so.1 will kill me. Am I
right on this ?
In any case I do not really like dlopen() approach. I saw it used this
way in zfs for iSCSI integration, but I do not think this case is
sufficiently similar to warrant copying it. I mentioned it for a
completeness purpose.
> For the dying Nevada SX:CE, libpciaccess is only in SUNWCuser and up,
> but prtconf is in SUNWCmreq (i.e., everything). ?This means that for
> SX:CE, you'd need to get the SUNWpciaccess package moved into
> SUNWCmreq in order to deliver any kind of a dependency on that
> library.
>
> For the OpenSolaris distribution, I'm not sure. ?I *think* it would be
> sufficient to declare that SUNWcsu (with the prtconf binaries) depends
> on SUNWpciaccess. ?You'd have to talk with the OpenSolaris team to
> confirm.
This actually brings an interesting question: To what extent should an
OpenSolaris developer, contributing code to OS/Net (or any other)
consolidation, worry about a particular distribution ?
It is probably not so complicated when you are talking about single
distribution produced by a single vendor. It can be significantly more
complicated when there are many different distributions produced by
various bodies. Shouldn't the task of deciding how exactly to package
the bits in hand for a particular distribution be handled by a
maintainers of a respective distribution ?
You've mentioned only two distributions (which coincidently being
produced by your employer). There are others distributions as well.
Should I talk to maintainers of each and every one of them as well ?
> If you're considering using dlopen() to work around this packaging
> issue, then, well, "yuck."
See above.
>> Would this change require any ARC involvement ?
>
> Yes.
>
> The cross-consolidation dependency itself isn't much of a problem.
> However, the stability level _is_ a problem.
>
> Depending on libpciaccess across a consolidation boundary does require
> ARC approval -- PSARC 2008/638 defined that interface as "Volatile,"
> and a requirement for a contract or an elevated stability level comes
> with that.
That's unfortunate.
Ok, if I want to move forward what should I do ? What would be the next step ?
--
Regards,
Cyril
