Cyril Plisko writes: > 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 ?
You're right about the functional difference, but it seems to me like an odd design. > > 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 ? That's a very good question, and I don't have a good answer, but I would point you towards the "best practice" documents in the Architecture Community. At least for architectural review, I can simplify things: those distributions that provide us with clear architectural information about their requirements will (and should) receive support from the architectural community. By incorporating those rules (whatever they are) into the best practices and other ARC documents, we will review projects with an eye towards their needs. Those distributions that do not do this will not receive similar support. They're on their own. (In case there's someone out there in the distribution world who would like to know how to get their rules included in the "best practices" and other ARC documents: it's simple; just work with any ARC member or intern to file a case with the proposed rules.) > 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 ? Unfortunately, that "how" part overlaps the development. It's possible for developers to make things that distributors would like to do either hard or impossible to accomplish. As a sort of obvious example, a project team could write some core OS service in Perl, and thus require every system to have Perl installed. If there's a distributor out there who doesn't want to ship Perl for some reason (space or licensing constraints?), he'd just be out of luck. I don't think we can split the issue up as cleanly as I think you're suggesting. Instead, we need to have *involvement* from the distributors in the review process, so that they understand (and have some say in) what they'll be getting as a result of development work. To the extent that they don't do this, they're at risk. > 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 ? I frankly don't have any architectural rules for any of those other distributions. They're a mystery to me, and one that I don't have time or inclination to go out and solve. If they bring requirements to the ARC, then that's great. If they don't, then I think they'll get what they get. As for advice to *you*, I think you should do what you think is right. If you believe that includes talking with those other maintainers, then do it. (If it were my project, I'm not sure I'd bother.) > > 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 ? Talk with the owner of that interface -- Stuart Kreitman and Alan Coopersmith. Ask them if they'll consider either raising the stability level (that's by far the *best* answer), or if they'd be willing to kludge around the problem by using an ARC contract. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
