PSARC/2008/549 - Apache Standard C++ Library
(Putting PSARC-ext back on distribution at request of Stefan.) Stefan Teleman wrote: > > > Garrett D'Amore wrote: >> It looks (from reading the README link you supplied) like there are >> some library utilities, localedef, etc. that are not part of your >> case but need to be. Your case materials are incomplete without a >> full list of what you intend to provide. > > These executables are not being delivered. the "locale" executable is > just a C++ version of the existing Solaris "locale" executable. There > is no need for this. OK. > > The "localedef" executable is a utility which only used at Library > build time, and which generates the character set conversion tables. > It plays no role after that, and it is not useful for inclusion. Ah, OK, sorry if I was confused from the Apache README. > >> The locations of the locale-specific data need to be fully exposed in >> the case materials as well. > > This location is provided in the ARC Case Materials, Appendix 2. > Please read all the ARC Case materials, completely. Sorry, I didn't see that. However, what I feel is still missing is how the data is manipulated. I.e., how do I generate l10n data. There is more than just a directory location here. (For example, with C's gettext(), I can use xgettext to extract data from the source, which can then be used to generate translations, and the translated files (whose format is specified in xgettext/gettext) can be stashed in documented location... you get the idea. Basically, anyone who is going to build a localized program, or provide localization data for such a program, needs to know certain information -- and that information is required in order for this case to be complete, IMO. > >> Saying your library provides i18n features without explaining *how* >> (or providing a link to a document that explains how) is inadequate. >> (And the Standard isn't sufficient either -- there are implementation >> specific behaviors that have to be specified as well.) > > What are these implementation specific behaviors ? How the implementation tracks down localized data, and what format it uses to interpret them. These are details of how users interact with the implementation that go beyond just the source code of the program. > > If they are implementation specific, therefore Project Private, why do > they have to be exposed as interfaces ? No. Implementation specific is *not* Project Private in this case. Unless you don't want to allow users to access any of those implementation specific details (which includes in this case the techniques used to publish locale specific data for new C++ programs.) > > Do any other ARC Cases which integrate external software document > Project Private implementation details ? Precedent, please. Again, not Project Private. But there are probably many precedents of publishing Project Private details. All one has to do is look for "Project Private" interface bindings in the ARC case log. Many Project Private details fall under the domain of "Architecture", even though ARC normally tends to focus on Interfaces. (See, for example, the cases associated with the FireEngine TCP stack in S10, which I think are almost entirely Project Private.) > > Do i also have to document all the private implementation details of > the std::iostream or std::string implementations ? Not if they are truly Project Private and not otherwise architectural. (I expect you don't need to, in other words.) > >> You still seem to be confusing the C++ ABI with the *binary* >> interfaces exposed by the library. (Binary interfaces are symbol >> names, semantics, etc.) Your library (all libraries!) offers an ABI, >> which is itself built upon the ABI supplied by the compiler. > > No, i am not confusing anything. > > Your understanding of ABI is valid in C. It is entirely inadequate, > and invalid, in C++. > > The Standard C++ Library is not just a shared library. It is also a > very large collection of templates, and classes. > > The classes provided in the Standard C++ Library contain virtual > methods. The presence of these methods determines the compiler to > create virtual tables, which become part of the binary representation > of the classes being compiled. Yes, I understand that. > > These templates provided by the Standard C++ Library are compiled > *into* the shared library, or executables, being built by the > consumer, including any and all virtual tables. These templates are > also compiled into the Standard C++ Library shared library being > delivered: libstdcxx.so.4 > > The consumer must link with the Standard C++ Library, libstdcxx.so.4. > In addition, the templates have been compiled into the application > built by the consumer. Yes, I understand that as well. > > As such, the ABI of the Library is comprised of everything i have > enumerated above: class definitions, class objects, automatic class > methods implicitly generate
[driver-discuss] Device Drivers Best Practice
This may or may not be OT, but I've always wondered what the official view of re-using the various DDI return statuses (i.e. DDI_SUCCESS and friends) within driver internal functions was. It seems that there are two main approaches used at the moment; this, and the use of boolean_t. Perhaps it may be useful to have an appendix dedicated to style? Garrett D'Amore wrote: > Vicki Abe wrote: >> Hiya, Garrett! >> >> Great idea - thanks for proactively putting a stake in the ground >> to document the process. >> > > No prob'. Recall this is a Best Practices document that is intended for > projects coming to ARC, not a replacement for information that belongs > in WDD or in a test plan. That may help frame some of my comments below. > >> One item that could be very helpful is to define clearly what is >> and is-not supported by the driver. For example, we may have a >> very basic driver for a sophisticated device -- the device may have >> several enhanced features that are not supported by the "plain vanilla" >> driver. >> > > This should be part of the ARC case for the driver or the man page of > the driver, I'd think. Unfortunately, there is no master of features > where such a description makes sense. Supporting Jumbo Frames is > important for ethernet drivers, but completely pointless for storage > drivers, or even other kinds of NIC driver, for example. > >> If we could distinguish in the man page between features that may exist >> in the chip, but may not be supported in the driver (a design decision), >> it would help to set user expectations correctly -- and avoid needless >> confusion (and customer calls). >> > > Yes, but this isn't architectural. This sounds like a potential docs > req't, and should be coordinated with the docs folks, IMO. > >> Also, if the driver carried versioning information (version of the DDI, >> version of the USB spec, version of the driver itself, version of the >> gld framework), this would help with maintenance and ongoing support >> for our drivers. >> > > There is no versioning of the DDI, although some specific interfaces are > versioned. This sounds more like a release engineering problem, > though. I'll note that bundled drivers carry the ON build they were > built as part of in the ELF comments (accessible via "what"). Other > kinds of versioning information would be hard to express universally, I > think. At least with our current DDI. If you want to enhance the DDI > for that, we'd need a specific proposal. In any case, its out of scope > for this Best Practices proposal (at least unless the DDI were enhanced > to express that information.) > >> We also noticed in a recent device driver class that we sponsored for >> IHVs, that driver developers coming from a Linux environment had some >> key differences in approach -- for example, their use of the watchdog >> interrupt is a common technique in Linux, but was actually a violation >> of the spirit of the Solaris DDI. >> > > Hmmm... I'm not sure how to express this difference in a best practices > document. > > Are you saying that these folks were hanging off a platform wide > watchdog for some other non-platform-specific driver? Weird. And yes, > not really in the spirit (or the letter, for that matter) of the DDI. > (timeout(9f) can be used to create soft watchdogs, though.) I'm not > sure I want to get into the philosophy of different design approaches, > but I think DDI compliance already covers the main concern here. > > (Conversely, if the device has its own internal watchdog timer that the > driver wishes to use to ensure proper function, I see no problem with that.) >> Can we add these items to your list? >> > I think most of the items you've mentioned probably have some other > context than what I'm intending the Best Practices document for. But > I'm happy to hear arguments to the contrary -- perhaps our Best > Practices guru (Plocher) would care to comment? > > -- Garrett > ___ > driver-discuss mailing list > driver-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/driver-discuss
[driver-discuss] Device Drivers Best Practice
Steven Stallion wrote: > This may or may not be OT, but I've always wondered what the official > view of re-using the various DDI return statuses (i.e. DDI_SUCCESS and > friends) within driver internal functions was. > > It seems that there are two main approaches used at the moment; this, > and the use of boolean_t. > > Perhaps it may be useful to have an appendix dedicated to style? > Style is, just that. I've used everything from DDI_SUCCESS and company, to errnos, to boolean_t's. Whatever seems most appropriate for the situation is what I do. I wouldn't try to impose a style about this on developers. -- Garrett > Garrett D'Amore wrote: > >> Vicki Abe wrote: >> >>> Hiya, Garrett! >>> >>> Great idea - thanks for proactively putting a stake in the ground >>> to document the process. >>> >>> >> No prob'. Recall this is a Best Practices document that is intended for >> projects coming to ARC, not a replacement for information that belongs >> in WDD or in a test plan. That may help frame some of my comments below. >> >> >>> One item that could be very helpful is to define clearly what is >>> and is-not supported by the driver. For example, we may have a >>> very basic driver for a sophisticated device -- the device may have >>> several enhanced features that are not supported by the "plain vanilla" >>> driver. >>> >>> >> This should be part of the ARC case for the driver or the man page of >> the driver, I'd think. Unfortunately, there is no master of features >> where such a description makes sense. Supporting Jumbo Frames is >> important for ethernet drivers, but completely pointless for storage >> drivers, or even other kinds of NIC driver, for example. >> >> >>> If we could distinguish in the man page between features that may exist >>> in the chip, but may not be supported in the driver (a design decision), >>> it would help to set user expectations correctly -- and avoid needless >>> confusion (and customer calls). >>> >>> >> Yes, but this isn't architectural. This sounds like a potential docs >> req't, and should be coordinated with the docs folks, IMO. >> >> >>> Also, if the driver carried versioning information (version of the DDI, >>> version of the USB spec, version of the driver itself, version of the >>> gld framework), this would help with maintenance and ongoing support >>> for our drivers. >>> >>> >> There is no versioning of the DDI, although some specific interfaces are >> versioned. This sounds more like a release engineering problem, >> though. I'll note that bundled drivers carry the ON build they were >> built as part of in the ELF comments (accessible via "what"). Other >> kinds of versioning information would be hard to express universally, I >> think. At least with our current DDI. If you want to enhance the DDI >> for that, we'd need a specific proposal. In any case, its out of scope >> for this Best Practices proposal (at least unless the DDI were enhanced >> to express that information.) >> >> >>> We also noticed in a recent device driver class that we sponsored for >>> IHVs, that driver developers coming from a Linux environment had some >>> key differences in approach -- for example, their use of the watchdog >>> interrupt is a common technique in Linux, but was actually a violation >>> of the spirit of the Solaris DDI. >>> >>> >> Hmmm... I'm not sure how to express this difference in a best practices >> document. >> >> Are you saying that these folks were hanging off a platform wide >> watchdog for some other non-platform-specific driver? Weird. And yes, >> not really in the spirit (or the letter, for that matter) of the DDI. >> (timeout(9f) can be used to create soft watchdogs, though.) I'm not >> sure I want to get into the philosophy of different design approaches, >> but I think DDI compliance already covers the main concern here. >> >> (Conversely, if the device has its own internal watchdog timer that the >> driver wishes to use to ensure proper function, I see no problem with that.) >> >>> Can we add these items to your list? >>> >>> >> I think most of the items you've mentioned probably have some other >> context than what I'm intending the Best Practices document for. But >> I'm happy to hear arguments to the contrary -- perhaps our Best >> Practices guru (Plocher) would care to comment? >> >> -- Garrett >> ___ >> driver-discuss mailing list >> driver-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/driver-discuss >>
LSARC/2008/550 - QT4 Framework
On 27/08/2008, at 9:29 PM, Darren J Moffat wrote: >>> Is this the common layout on Linux based distributions where GNOME >>> is >>> considered the primary desktop rather than KDE ? What is they >>> layout >>> when KDE is the primary desktop ? >> >> SUSE organizes as /usr/lib/qt3 /usr/lib/qt4, etc > > where are the include files on SUSE ? > > Why is your layout better than the SUSE one ? What problems does it > solve that their layout doesn't ? Fedora puts things into /usr/lib for the most part, with some versioning for the plugins and phrasebooks - http://koji.fedoraproject.org/koji/rpminfo?rpmID=697994 Glynn
Terminator for OpenSolaris [LSARC/2008/554 FastTrack timeout 09/03/2008]
Does this terminal emulator use an existing TERM value/terminfo entry or is a new one required for it? -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
Terminator for OpenSolaris [LSARC/2008/554 FastTrack timeout 09/03/2008]
Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Terminator for OpenSolaris 1.2. Name of Document Author/Supplier: Author: Luis De 1.3 Date of This Document: 27 August, 2008 4. Technical Description 1. Introduction 1.1. Project/Component Working Name: Terminator 1.2. Name of Document Author/Supplier: Luis de Bethencourt 1.3. Date of This Document: 1/08/2008 1.3.1. Date this project was conceived: 03/06/2008 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: Solaris PAC 1.4.2. The ARC(s) you expect to review your project: LSARC 1.4.3. The Director/VP who is "Sponsoring" this project: robert.odea at sun.com 1.4.4. The name of your business unit: OPG / OpenSource. 1.5. Email Aliases: 1.5.1. Responsible Manager: tom.garland at sun.com 1.5.2. Responsible Engineer: luis.debethencourt at sun.com 1.5.3. Marketing Manager: dan.roberts at sun.coma 1.5.4. Interest List: desktop-discuss at opensolaris.org 4. Technical Description: 4.1. Details: A terminal emulator that lets the user arrange multiple terminals by splitting vertically or horizontally the window space recursively. It is inspired by the splitting functionality of vim, in that the main focus is arranging terminals in grids (tabs is the most common default method, which Terminator also supports). Many of the features are intended to be useful for sysadmins. Version: 0.9 This is an Open Source package. 4.2. Bug/RFE Number(s): 6735889. 4.3. In Scope: See above. 4.4. Out of Scope: See above. 4.5. Interfaces: ExportedStability Comments SUNWterminator Uncommited /usr/bin/terminator Uncommited Command /usr/share/applications/terminator.desktop Volatile Desktop menu entry /usr/share/doc/terminator Project Private Documentation ImportedStability Comments python VolatilePSARC 2005/532 gnome-pythonVolatileLSARC 2005/506 and LSARC 2008/207 case. 4.6. Doc Impact: New manpage, terminator.1. 4.7. Admin/Config Impact: None. 4.8. HA Impact: None. 4.9. I18N/L10N Impact: The JDS team and the G11N are working together to evaluate and provide I18N/L10N support. 4.10. Packaging & Delivery: Adds new package, SUNWterminator 4.11. Security Impact: None. 4.12. Dependencies: Terminator depends of the software listed in the Imported Interfaces section. 5. Reference Documents: The Terminator homepage: http://www.tenshu.net/terminator/ The Terminator project development page: https://launchpad.net/terminator/ 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: Desktop 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open
[driver-discuss] Device Drivers Best Practice
Edward Shu wrote: > Garrett D'Amore : >> 3. Independence from firmware initialization. Device drivers should >> not >> depend on firmware to initialize devices. While certain portions of >> the device may be initialized by OS or BIOS (assignment of PCI >> addresses to BARs for example), device drivers should not rely on >> firmware to perform any device specific initialization. >> >> >> >In fact, it is really unfortunately that some of our device > drivers must depend on the firmware initialization, like > graphics, disk drivers because we can not get help from vendors. > Even, some firmware must be downloaded into > system memory. Yes, its really unfortunate. However, some developers have relied on this initialization even when they didn't have to. A certain famous storage adapter had this problem, and ultimately led to the creation of the Fcode project. (One of the things that such drivers have a problem with is hotplug, because in hotplug there is no firmware initialization. It also creates a serious problem for S3 resume.) -- Garrett >> ___ >> driver-discuss mailing list >> driver-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/driver-discuss >> > >
LSARC/2008/550 - QT4 Framework
On Tue, 2008-08-26 at 14:35 -0400, Stefan Teleman wrote:
> > Is there no pkg-config .pc file for QT that can be placed in
> > /usr/lib/pkgconfig to help with this ?
>
> PKG_CONFIG_PATH can be set to /usr/qt4/4.4.1/lib/pkgconfig:
> ${PKG_CONFIG_PATH}.
>
> Or, one can say --with-qt-include=${QTDIR}/include --with-qt-libs=
> ${QTDIR}/lib
The problem is that for people who naively try to build Qt apps
on Solaris, it will seem that there is no Qt on Solaris.
It would be really nice to symlink the pc files of the latest
version to /usr/lib/pkgconfig.
Laca
LSARC/2008/550 - QT4 Framework
Marc Glisse wrote: >> The question is: what happens when we want to include >> a newer version of QT (QT >> 4.5.0 is already out), which comes with newer and >> likeable features ? The two >> versions have to be able to coexist someohow, without >> creating conflicts. > > Do you have evidence about the lack of backwards compatibility of Qt 4.5.0 > with 4.4.1 (or even 4.0.0 for that matter)? > It looks like Trolltech really tries to maintain backwards compatibility in > minor upgrades, not only patch upgrades. I don't have evidence about the two particular versions you mention, but i do have evidence about 4.3.1 vs. 4.3.3. Using 4.3.3 with the 4.3.1 compiled KDE4 did not work. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
LSARC/2008/550 - QT4 Framework
Darren J Moffat wrote: > Stefan Teleman wrote: >> >> Darren J Moffat wrote: >> In /usr/include, which I believe is inconsistent, and wrong. >>> Why ? /usr/include is where include files usually live and where they >>> are looked for by default. >> 1. How are we going to deliver multiple versions of QT? > > Is that actually a problem that needs to be solved ? Do we really need > to have multiple versions of QT installed ? Is this what everyone else > does or do they pick one version per release of their os/distribution ? Consider that we only ship one version of GNOME and its libraries and that is the OpenSolaris main desktop. -- Darren J Moffat
[driver-discuss] Device Drivers Best Practice
Garrett D'Amore writes: > > If we could distinguish in the man page between features that may exist > > in the chip, but may not be supported in the driver (a design decision), > > it would help to set user expectations correctly -- and avoid needless > > confusion (and customer calls). > > > > Yes, but this isn't architectural. This sounds like a potential docs > req't, and should be coordinated with the docs folks, IMO. The bounds of 'system architecture' can be fairly flexible, and can certainly extend to hardware interfaces. The idea that a driver may not provide access to all of the features of the underlying hardware does sound to me like a potential architectural limitation for the system as a whole. (It's analogous to having a middleware wrapper that obscures features in the underlying system -- that's architectural, too.) As a best practice item, and since we're potentially already recommending things here that are arguably beneath the level of architecture, I think it makes a lot of sense to say that if you're doing anything unusual, you should document it, and that (among the many "unusual" things you might do) failing to support the features in the hardware (or simply deciding not to) is something that needs to be disclosed clearly in the customer-visible documentation. Similarly, failing to support the features that are "common" in drivers of the same ilk is a good thing to document. For example, an Ethernet driver that can't do VLANs stands out, and needs a note. > kinds of versioning information would be hard to express universally, I > think. At least with our current DDI. If you want to enhance the DDI > for that, we'd need a specific proposal. In any case, its out of scope > for this Best Practices proposal (at least unless the DDI were enhanced > to express that information.) Agreed; it's really a packaging issue. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
LSARC/2008/550 - QT4 Framework
Stefan Teleman wrote: > > > Darren J Moffat wrote: > >>> In /usr/include, which I believe is inconsistent, and wrong. >> >> Why ? /usr/include is where include files usually live and where they >> are looked for by default. > > 1. How are we going to deliver multiple versions of QT? Is that actually a problem that needs to be solved ? Do we really need to have multiple versions of QT installed ? Is this what everyone else does or do they pick one version per release of their os/distribution ? If it is why not /usr/include/qt4/4.4.1/ rather than /usr/qt4/4.4.1/include ? > 2. If we do not deliver multiple versions of QT, and we overwrite the > header files in /usr/include every time we uprev, we run the risk of > breaking API and ABI. I hope the ABI doesn't break because the header files changed. That might be the behaviour you actually want - force things being built to use the newer version but still deliver the older libraries so that existing binaries still run (just like we have done in the past for other "gui" libraries like motif). -- Darren J Moffat
[driver-discuss] Device Drivers Best Practice
Good point. Maybe someone else here can write specific advice about virt'n concerns for drivers. - Garrett John Levon wrote: > On Wed, Aug 27, 2008 at 01:05:10PM -0700, Garrett D'Amore wrote: > > >> So I've undertaken to write a replacement. Here's a draft. Note that >> this is not in the format for BPs. We can correct that later -- mostly >> I want to offer this up for a general review/comment/feedback at this >> point, and once we have the content mostly stable, I'll submit a new >> case for it. >> > > I think you should at least mention virtualization as a general issue. > For example, under xVM, old-style port I/O is rather slow. > > regards > john > ___ > driver-discuss mailing list > driver-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/driver-discuss >
LSARC/2008/550 - QT4 Framework
Stefan Teleman wrote:
>
>
> Darren J Moffat wrote:
>
>> The pkg-config file should be in /usr/lib/pkgconfig we already set
>> precedence for this in other cases. I have no problem with providing
>> multiple pkgconfig files under the path you gave but the canonical
>> version of qt should have one in /usr/lib/pkgconfig
>
> Which version of QT is the "canonical version of qt" ?
>
> 4.4.1 ? 4.5.0 ?
>
> Trolltech makes no claims as to any of QT4's versions being "canonical".
That is for the project team too choose. Just like the project teams
for things like perl, python, mysql and all those other projects that
ship multiple versions often have to.
>>> Or, one can say --with-qt-include=${QTDIR}/include
>>> --with-qt-libs=${QTDIR}/lib
>>
>> $QTDIR isn't defined in my environment.
>
Is this the common layout on Linux based distributions where GNOME
is considered the primary desktop rather than KDE ? What is they
layout when KDE is the primary desktop ?
>>>
>>> SUSE organizes as /usr/lib/qt3 /usr/lib/qt4, etc
>>
>> where are the include files on SUSE ?
>
> In /usr/include, which I believe is inconsistent, and wrong.
Why ? /usr/include is where include files usually live and where they
are looked for by default.
Why are you trying to hide this somewhere else ? We learn't from
/usr/sfw that it only causes pain.
>> Why is your layout better than the SUSE one ? What problems does it
>> solve that their layout doesn't ?
>
> The layout proposed here follows the layout established by the Perl ARC
> Case PSARC/1999/192.
There is a /usr/bin/perl even with that layout, your proposal has no
equivalent.
> I don't know if it's "better" than Linux, I don't particularily consider
> Linux a benchmark for adjudicating the soundness of directory layouts,
> and I prefer following established precedents which have been sanctioned
> and approved by the ARCs.
That is all well and good but don't just copy cases that are 8 years old
think about the environment we are in now.
>>> It can't be Committed because [1] it doesn't really implement any
>>> known Industry standard,
>>
>> That isn't the definition of committed.
>
> http://opensolaris.org/os/community/arc/policies/interface-taxonomy/
>
> It appears to be one of the attributes to be taken into consideration
> when assigning a Committed stability level to an Interface, or a group
> of Interfaces. Given that QT does not implement a known Industry
> Standard, that's strike one against Committed.
It isn't the only one though.
>> > and [2] we don't control QT's Interface Stability level.
>>
>> Then what was all that text above about ? It can be Committed if the
>> project team believes that the upstream behaves in a manner suitable.
>> The text you provided indicates you do think that.
>
> Considering the ABI Micro
> Release Stability guarantee provided by Trolltech ASA, a
> "Committed" Interface Stability Classification would have been
> appropriate.
>
> The project team does not believe that, nor do the ARC Case Documents
> imply that the project team believes that. The ARC Case documents
> clearly states that this ABI stability guarantee is provided by
> Trolltech, and this guarantee only applies to Micro releases.
That to me contracts the very sentence you wrote and just quoted. It
acutally says that Committed would have been appropriate.
> Is an interface stability guarantee which is effective only for Micro
> releases appropriate for "Committed" ? I do not believe that it is. We
> are saying that "QT 4.4.1 will be ABI and API compatible with 4.4.3, but
> not with 4.5.0".
If you ship 4.4.x and 4.5.x at the same time yes.
> This does not qualify for "Committed". That's strike two against Committed.
I disagree but I don't care enough to argue with you about it since in
reality it makes no difference what so ever to how QT will be used.
Leave it at Uncomitted.
--
Darren J Moffat
ncurses for OpenSolaris [LSARC/2008/524 FastTrack timeout 08/22/2008]
Hi, Latest version materials. Shipping wide-char version using lib*.so name. -rick -- next part -- An embedded and charset-unspecified text was scrubbed... Name: ncurses-proposal.txt URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080827/167f9c3f/attachment.txt>
ncurses for OpenSolaris [LSARC/2008/524 FastTrack timeout 08/22/2008]
Hi, all I am extending the timeout to be Sept 1st --Irene Danek Duvall wrote: > On Tue, Aug 26, 2008 at 10:51:24AM +0800, Irene Huang wrote: > > >> If no one disagrees, I would like to close this case within 24 hours :) >> > > Don't rush. I don't think we're done yet. At the very least, the next > round of materials needs to be sent out, as well as the answer to whether > libncurses.so.5 should be wide-char enabled or whether there should be both > libncurses.so.5 (narrow) and libncursesw.so.5 (wide). > > Danek >
add top utility to SFW consolidation [PSARC/2008/533 FastTrack time out 08/26/2008]
Don Cragun wrote: >> Date: Wed, 27 Aug 2008 10:24:24 +0100 >> From: Darren J Moffat >> >> Don Cragun wrote: >>> Since all open issues have been resolved and there have been no >>> additional comments for the last six days, I'm marking this case >>> closed approved. >> I was still waiting on a proper spec as I had asked for so I'm very >> surprised to see this as closed. The reason I hadn't commented was >> because there is no spec to comment on, just a copy of the top man page. >> >> What is the release binding, interface taxonomy, package name etc. None >> of that is covered in the man page. > > Quoting from the first message sent to this case's mail log: > "The project team is requesting a minor release binding." I didn't see that as relevant given how the case morphed from a symlink to prstat to actually shipping the real top. > If you were concerned that the interface taxonomy and package name were > not covered, I would have expected you to request that information > before the case timed out; It was implicit in my message with ID: Date: Wed, 20 Aug 2008 17:50:39 +0100 Message-id: <48AC4B5F.6010407 at Sun.COM> > I see no request for that information in the > mail log. (It is also interesting to note that there is no interface > taxonomy listed on the prstat(1M) man page.) I shouldn't have to ask it is required information for an ARC case. > I will get the interface taxonomy and package name from the project > team later this morning. In the interest of not playing fetch a rock, > what other information are you expecting when you say "etc."? The basic information we would expect from any fast-track case. Specifically I want to see the following: * Package name * Taxonomy of top functionality: cli arguments package name * Install location of top - I assume it is /usr/bin/top but this must be explicit -- Darren J Moffat
ncurses for OpenSolaris [LSARC/2008/524 FastTrack timeout 08/22/2008]
(I know it is too late to comment) > With wide char supported, there is only > libncursesw.so instead of > libncurses.so. I thought there should be either libncurses.so.5 or libncursesw.so.5, never mind which (it could even be a weirder name), but it would be most convenient to provide both libncurses.so and libncursesw.so symlinks. This message posted from opensolaris.org
PSARC/2008/542 - libffi - Foreign Function Interface library
That worked, thanks Brian and Google :) So the dependency on libgcc_s.so.1 is not necessary and will be removed from the imported interfaces table. Laca On Tue, 2008-08-26 at 22:26 +0100, Brian Ruthven - Solaris Network Sustaining - Sun UK wrote: > Can't it be eliminated with something like -s?tatic-libgcc ? At least > that's what Google tells me I can do :-) > Or is it specifically required that the libgcc_s library is external > (i.e. dynamically loaded) rather than statically linked in at compile time? > > Brian > > Laszlo (Laca) Peter wrote: > > On Fri, 2008-08-22 at 17:17 -0700, Danek Duvall wrote: > > > >>> 2.2 Imported Interfaces > >>> > >>> Interface Classification Comments > >>> - -- -- > >>> libgcc_s.so.1 VolatilePSARC/2004/742 > >>> > >> Couldn't this be eliminated by using the Studio compiler? > >> > > > > It would, but libffi contains ASM code that doesn't build with > > Sun Studio. It may be possible to build it with a future > > version of Sun Studio. > > ? > > > >> Or does Python require gcc? > >> > > > > No. > > > > Laca > > > >
PSARC 2008/551 coreadm configuration refinements
David Powell wrote: > Scott Rotondo wrote: >> I fully support the changes described here, but I have a couple of >> comments/questions about minor details. >> >> 1. The man page should document the specific authorizations needed, >> just as it used to document the specific privilege. It's fine to >> mention that the Maintenance and Repair profile provides these >> authorizations, but they could be provided by other profiles also. [In >> other words, the authorization name is the real interface, not the >> profile name.] >> >>> Multiple -e and -d options can be specified on >>> - the command line. Only users with the sys_admin >>> - privilege can use this option. >>> + the command line. Only users and roles belonging >>> + to the "Maintenance and Repair" RBAC profile can >>> + use this option. >> >> Suggest: Only users and roles with the solaris.smf.manage.coreadm and >> solaris.smf.value.coreadm authorizations can use this option. > > When researching the case, I was advised to look at the dladm man > page. It takes the approach of documenting the necessary profile. > > I'm not wedded to either approach, though I have to say that the > profile has the appeal of being an interface that can be more easily > maintained in the face of implementation changes. i.e. if the > previously documented mechanism actually worked, I would have been > more concerned about changing coreadm from requiring privileges to > requiring authorizations. If it had been documented in terms of the > profile, there would be no cause for concern regardless of the > change. > > Given this, the precedent set by dladm, and that in the common case > coreadm users should just be using the provided profile (i.e. > referring first to the profile makes the man page more useful > documentation), would it instead be acceptable to document the > authorizations in an auxiliary section (e.g. NOTES) leaving the > profile as the "primary" documented interface? So apparently there is more divided opinion on this issue than I thought. Who would have guessed? ;-) I think that individual privilege and authorization names should be the stable interfaces presented to administrators rather than the names of RBAC profiles that contain them. My reasons for this view include the following: 1. There are other, equally valid, ways for users to acquire authorizations and processes to acquire privileges besides the use of RBAC profiles. Individual privileges and authorizations can be specified in user_attr entries and in SMF service manifests. Many processes also gain privileges by running with uid 0. 2. There is no intent to prevent overlap between RBAC profiles. The same authorization, for example, may be granted by multiple profiles included in Solaris, as well as additional ones defined by the user. In such an environment, there is no obvious rationale for selecting which profile to specify on a man page like this one. 3. Authorizations and privileges exist in order to allow an administrator to implement the principle of least privilege, i.e. to grant a minimal set of rights needed to accomplish a particular purpose. In order to construct such a set, an administrator needs to know the function of each privilege or authorization and needs to know which ones are required by each administrative program. 4. Privilege names, at least, cannot be considered as implementation details that are subject to change within an RBAC profile because the specific privileges are documented on the man pages of system calls that require them. Although this argument does not apply to authorizations, I think they should be treated similarly for the reasons described above. Having said all that, this is a general architectural issue that should not hold up the current fast-track. PSARC members: What is the best mechanism to reach consensus on this issue and ensure that current and future documentation complies with that consensus? Scott
LSARC/2008/550 - QT4 Framework
> The question is: what happens when we want to include > a newer version of QT (QT > 4.5.0 is already out), which comes with newer and > likeable features ? The two > versions have to be able to coexist someohow, without > creating conflicts. Do you have evidence about the lack of backwards compatibility of Qt 4.5.0 with 4.4.1 (or even 4.0.0 for that matter)? It looks like Trolltech really tries to maintain backwards compatibility in minor upgrades, not only patch upgrades. This message posted from opensolaris.org
[driver-discuss] Device Drivers Best Practice
Vicki Abe wrote: > Hiya, Garrett! > > Great idea - thanks for proactively putting a stake in the ground > to document the process. > No prob'. Recall this is a Best Practices document that is intended for projects coming to ARC, not a replacement for information that belongs in WDD or in a test plan. That may help frame some of my comments below. > One item that could be very helpful is to define clearly what is > and is-not supported by the driver. For example, we may have a > very basic driver for a sophisticated device -- the device may have > several enhanced features that are not supported by the "plain vanilla" > driver. > This should be part of the ARC case for the driver or the man page of the driver, I'd think. Unfortunately, there is no master of features where such a description makes sense. Supporting Jumbo Frames is important for ethernet drivers, but completely pointless for storage drivers, or even other kinds of NIC driver, for example. > If we could distinguish in the man page between features that may exist > in the chip, but may not be supported in the driver (a design decision), > it would help to set user expectations correctly -- and avoid needless > confusion (and customer calls). > Yes, but this isn't architectural. This sounds like a potential docs req't, and should be coordinated with the docs folks, IMO. > Also, if the driver carried versioning information (version of the DDI, > version of the USB spec, version of the driver itself, version of the > gld framework), this would help with maintenance and ongoing support > for our drivers. > There is no versioning of the DDI, although some specific interfaces are versioned. This sounds more like a release engineering problem, though. I'll note that bundled drivers carry the ON build they were built as part of in the ELF comments (accessible via "what"). Other kinds of versioning information would be hard to express universally, I think. At least with our current DDI. If you want to enhance the DDI for that, we'd need a specific proposal. In any case, its out of scope for this Best Practices proposal (at least unless the DDI were enhanced to express that information.) > We also noticed in a recent device driver class that we sponsored for > IHVs, that driver developers coming from a Linux environment had some > key differences in approach -- for example, their use of the watchdog > interrupt is a common technique in Linux, but was actually a violation > of the spirit of the Solaris DDI. > Hmmm... I'm not sure how to express this difference in a best practices document. Are you saying that these folks were hanging off a platform wide watchdog for some other non-platform-specific driver? Weird. And yes, not really in the spirit (or the letter, for that matter) of the DDI. (timeout(9f) can be used to create soft watchdogs, though.) I'm not sure I want to get into the philosophy of different design approaches, but I think DDI compliance already covers the main concern here. (Conversely, if the device has its own internal watchdog timer that the driver wishes to use to ensure proper function, I see no problem with that.) > Can we add these items to your list? > I think most of the items you've mentioned probably have some other context than what I'm intending the Best Practices document for. But I'm happy to hear arguments to the contrary -- perhaps our Best Practices guru (Plocher) would care to comment? -- Garrett
Device Drivers Best Practice
Hiya, Garrett! Great idea - thanks for proactively putting a stake in the ground to document the process. One item that could be very helpful is to define clearly what is and is-not supported by the driver. For example, we may have a very basic driver for a sophisticated device -- the device may have several enhanced features that are not supported by the "plain vanilla" driver. If we could distinguish in the man page between features that may exist in the chip, but may not be supported in the driver (a design decision), it would help to set user expectations correctly -- and avoid needless confusion (and customer calls). Also, if the driver carried versioning information (version of the DDI, version of the USB spec, version of the driver itself, version of the gld framework), this would help with maintenance and ongoing support for our drivers. We also noticed in a recent device driver class that we sponsored for IHVs, that driver developers coming from a Linux environment had some key differences in approach -- for example, their use of the watchdog interrupt is a common technique in Linux, but was actually a violation of the spirit of the Solaris DDI. Can we add these items to your list? -- thanks, --vla =:-) Vicki Abe Accessline number: (408) 404-6916 (x.69966) Solaris x86 IHV Engineering Team Garrett D'Amore wrote: > During today's PSARC meeting, we talked about best practices. One of > the ones that seemed pretty stale and incomplete was the one for device > drivers (see > http://www.opensolaris.org/os/community/arc/bestpractices/bp-device-drivers/ > ) > > So I've undertaken to write a replacement. Here's a draft. Note that > this is not in the format for BPs. We can correct that later -- mostly > I want to offer this up for a general review/comment/feedback at this > point, and once we have the content mostly stable, I'll submit a new > case for it. > > So, here's what I have. Some of the items listed below may never have > been expressed in any other document before: > > Device Drivers Best Practices > - > > 1. DDI conformance. Device drivers for bundled device drivers SHOULD >adhere to the documented DDI, using only header files, functions, > macros, >structures, and fields that are documented. Note that this precludes >taking the sizeof() certain structures (struct msgb, struct datab, > struct >buf) which are intended to be dynamically allocated. Unbundled device >drivers MUST adhere to the documented DDI, or obtain contracts for any >exceptions required. > > 2. Proper use of bus/device type specific APIs where applicable. Drivers >SHOULD, when possible, use the latest driver frameworks for certain >types of driver, rather than reimplementing common functionality. For >example, NIC drivers should use the GLD, and SCSI drivers should use the >SCSA framework and USB drivers should use the USB framework. > > 3. Independence from firmware initialization. Device drivers should not >depend on firmware to initialize devices. While certain portions of >the device may be initialized by OS or BIOS (assignment of PCI >addresses to BARs for example), device drivers should not rely on >firmware to perform any device specific initialization. > > 4. Support for DDI_SUSPEND and DDI_RESUME. Device drivers must properly >support DDI_SUSPEND and DDI_RESUME, including dealing with a potential >loss of power in between. Note that system firmware may not execute >on resume, so adherence to #3 above will help greatly. Pseudo-drivers >generally don't have to worry about this, and certain kinds of hardware >drivers may be able to rely on their bus parents to properly shutdown >the device. > > 5. Support for quiesce(9e). In order to facilitate fast-reboot, > drivers should >support the quiesce(9e) DDI entry point. (Not applicable to Solaris > 10 or >earlier.) > > 6. Support for power management. If possible, devices should support >fine grained power management to reduce overall power consumption on >the platform. See power(9e). > > 7. Portability. Device drivers should avoid assumptions about the >platform they are to run on. A driver should be coded to operate >properly on either SPARC or x86 CPUs. Drivers should not make > assumptions >about the cache, endian, or word size attributes of the host > platform, and >proerly make use of Solaris interfaces such as ddi_dma_sync(9f), >ddi_get32(9f), etc. > > 8. MP safety. All device drivers must be MP-hot. That is, they must > assume >that entry points and interrupts can all run synchronously, and make use >of synchronization guards (mutex_enter(9f) or similar) to ensure correct >operation. > > 9. Fault tolerance.
[driver-discuss] Device Drivers Best Practice
Artem Kachitchkine wrote: > > Would it also be appropriate to point to the Writing Device Drivers > book as required reading for any driver writer? Besides essential > technical info, it includes some best practices -ish advice, as in > chapters: > > Considerations in Device Driver Design > Choosing a Locking Scheme > Defensive Programming Techniques for Solaris Device Drivers > Debugging, Testing, and Tuning Device Drivers > Recommended Coding Practices > > -Artem Good idea. -- Garrett
OpenARC Serviceability Guidelines [LSARC/2008/547 FastTrack timeout 09/02/2008]
Though we should somehow express that we consider these "good practices" that we would welcome (or at least leave the door open for) FOSS folks to learn from or debate as well. So while we might not strictly require others to follow, we are happy to lead. bill. John Fischer wrote: > Tom, > > Yesterday during LSARC you stated something about the > intent of these guidelines were not necessarily at > FOSS projects. Is that correct? If so then perhaps > a short preamble is required for the guidelines. > > Thanks, > > John > > On Tue, 2008-08-26 at 12:11, Tom Childers wrote: >> Here is an updated version of the guidelines document for this case, >> incorporating the feedback so far. >> >> The doc is available at >> http://www.opensolaris.org/os/community/arc/caselog/2008/547/ >> , and the new versions should propagate to the opensolaris.org web >> page soon. >> -tdc >> >> >
Device Drivers Best Practice
On Wed, 27 Aug 2008, Garrett D'Amore wrote: > 4. Support for DDI_SUSPEND and DDI_RESUME. Device drivers must properly >support DDI_SUSPEND and DDI_RESUME, including dealing with a potential >loss of power in between. Note that system firmware may not execute >on resume, so adherence to #3 above will help greatly. Pseudo-drivers >generally don't have to worry about this, and certain kinds of hardware >drivers may be able to rely on their bus parents to properly shutdown >the device. > > > 17. Proper support for hotplug where applicable. A driver for a removable >system peripheral must support hot insertion and removal. Via >attach(9e) and detach(9e). Note that PCI and PCI express busses are >hotpluggable on some platforms. > Not certain where this should be added, but it should be noted that the "hotplugging" can occur while suspended, and drivers that have notion of this (as a good example, USB devices), should be able to handle the removal or insertion while suspended on resume. It might, though, make sense to have this blocked so that there is a section for suspend/resume and/or power management (could also apply to other driver classes). Randy
/PSARC/2008/482 - NWAM Phase 0.5 (picea)
John Fischer writes: > Having received no comment on this opinion and a week > has passed I am going to forward this to SAC. There are two contracts on the way. I don't think they affect much (one for use of libbsm and the other between the GUI and ON teams within the project), but as a procedural bit, I think they should be there before the case is closed. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
[driver-discuss] Device Drivers Best Practice
Would it also be appropriate to point to the Writing Device Drivers book as required reading for any driver writer? Besides essential technical info, it includes some best practices -ish advice, as in chapters: Considerations in Device Driver Design Choosing a Locking Scheme Defensive Programming Techniques for Solaris Device Drivers Debugging, Testing, and Tuning Device Drivers Recommended Coding Practices -Artem
Device Drivers Best Practice
During today's PSARC meeting, we talked about best practices. One of the ones that seemed pretty stale and incomplete was the one for device drivers (see http://www.opensolaris.org/os/community/arc/bestpractices/bp-device-drivers/ ) So I've undertaken to write a replacement. Here's a draft. Note that this is not in the format for BPs. We can correct that later -- mostly I want to offer this up for a general review/comment/feedback at this point, and once we have the content mostly stable, I'll submit a new case for it. So, here's what I have. Some of the items listed below may never have been expressed in any other document before: Device Drivers Best Practices - 1. DDI conformance. Device drivers for bundled device drivers SHOULD adhere to the documented DDI, using only header files, functions, macros, structures, and fields that are documented. Note that this precludes taking the sizeof() certain structures (struct msgb, struct datab, struct buf) which are intended to be dynamically allocated. Unbundled device drivers MUST adhere to the documented DDI, or obtain contracts for any exceptions required. 2. Proper use of bus/device type specific APIs where applicable. Drivers SHOULD, when possible, use the latest driver frameworks for certain types of driver, rather than reimplementing common functionality. For example, NIC drivers should use the GLD, and SCSI drivers should use the SCSA framework and USB drivers should use the USB framework. 3. Independence from firmware initialization. Device drivers should not depend on firmware to initialize devices. While certain portions of the device may be initialized by OS or BIOS (assignment of PCI addresses to BARs for example), device drivers should not rely on firmware to perform any device specific initialization. 4. Support for DDI_SUSPEND and DDI_RESUME. Device drivers must properly support DDI_SUSPEND and DDI_RESUME, including dealing with a potential loss of power in between. Note that system firmware may not execute on resume, so adherence to #3 above will help greatly. Pseudo-drivers generally don't have to worry about this, and certain kinds of hardware drivers may be able to rely on their bus parents to properly shutdown the device. 5. Support for quiesce(9e). In order to facilitate fast-reboot, drivers should support the quiesce(9e) DDI entry point. (Not applicable to Solaris 10 or earlier.) 6. Support for power management. If possible, devices should support fine grained power management to reduce overall power consumption on the platform. See power(9e). 7. Portability. Device drivers should avoid assumptions about the platform they are to run on. A driver should be coded to operate properly on either SPARC or x86 CPUs. Drivers should not make assumptions about the cache, endian, or word size attributes of the host platform, and proerly make use of Solaris interfaces such as ddi_dma_sync(9f), ddi_get32(9f), etc. 8. MP safety. All device drivers must be MP-hot. That is, they must assume that entry points and interrupts can all run synchronously, and make use of synchronization guards (mutex_enter(9f) or similar) to ensure correct operation. 9. Fault tolerance. Device drivers MUST NEVER panic in response to bad data received from a source outside of the kernel address space. That means that data received from a physical device (disk, network, etc.) must be validated before used in the kernel, as well as data that comes from user-space. Device drivers should use watchdogs or similar to guard against device failure. Device drivers should make use of FMA interfaces to handle and report fault conditions. 10. Userland interaction. Device drivers that interact with userland must be able to deal with either 32-bit or 64-bit applications, performing any word size conversions as necessary. (Note that no conversion is necessary when the kernel is running in 32-bit mode.) See ddi_get_model(9F). 11. Avoiding polling. Drivers should avoid polling whenever possible, particularly in long running situations. Polling prevents the CPU from reaching idle state, and increases power consumption for the entire platform. 12. Do not depend on the system clock rate. The value of HZ can be different across reboots. drv_usectohz(9f) can be used if an absolute time is required. 13. Minimize time running in interrupt context. This is a general guideline for all device drivers. 14. Avoid use of custom tracing or debugging facilities. Use DTrace instead. 15. Observability. Drivers SHOULD properly report their operation via the appropriate kstat(9s)'s for their driver type. This includes correct accounting of I/O times (kstat_io(9s)) and interrupts (kstat_intr(9s)). 1
LSARC/2008/550 - QT4 Framework
Darren J Moffat wrote: >> 1. How are we going to deliver multiple versions of QT? > > Is that actually a problem that needs to be solved ? Do we really need > to have multiple versions of QT installed ? Is this what everyone else > does or do they pick one version per release of their os/distribution ? I believe so, yes. Linux doesn't do this. But then Linux liberally breaks things. The result of this is: any 3rd party Linux application which uses QT, delivers their own private copy of QT: Google Earth, Skype first come to mind. Even KDE. Why do they do this ? Because they can't rely on any sense of stability with the QT provided by the Linux distros. Wouldn't it be nice to provide our consumers of our QT some measure of stability ? > If it is why not /usr/include/qt4/4.4.1/ rather than > /usr/qt4/4.4.1/include ? I can change it. But the idea was to have every version of QT4 in its own directory under /usr/qt4/. > >> 2. If we do not deliver multiple versions of QT, and we overwrite the >> header files in /usr/include every time we uprev, we run the risk of >> breaking API and ABI. > > I hope the ABI doesn't break because the header files changed. It can, and it will, this is C++, and there are templates, virtual tables and inline functions. > That might be the behaviour you actually want - force things being built > to use the newer version but still deliver the older libraries so that > existing binaries still run (just like we have done in the past for > other "gui" libraries like motif). I was thinking of doing that for the process of "obsoleting" a QT version: removing the executables, header files, and ancillary files, and only leaving the libraries around. That makes applications linked against QT still work, but prevents creating new applications against the obsolete version. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
OpenARC Serviceability Guidelines [LSARC/2008/547 FastTrack timeout 09/02/2008]
Gary and I are intending these guidelines for the FOSS community, and would certainly like to provide a feedback mechanism. That's why it's an open case. If there is a way we can do this beyond the OpenARC process, I'd like to know. -tdc On Aug 27, 2008, at 10:45 AM, Bill Walker wrote: > > Though we should somehow express that we consider these "good > practices" that we would welcome (or at least leave the door open > for) FOSS folks to learn from or debate as well. So while we might > not strictly require others to follow, we are happy to lead. > > bill. > > > John Fischer wrote: >> Tom, >> Yesterday during LSARC you stated something about the intent of >> these guidelines were not necessarily at >> FOSS projects. Is that correct? If so then perhaps >> a short preamble is required for the guidelines. >> Thanks, >> John >> On Tue, 2008-08-26 at 12:11, Tom Childers wrote: >>> Here is an updated version of the guidelines document for this >>> case, incorporating the feedback so far. >>> >>> The doc is available at >>> http://www.opensolaris.org/os/community/arc/caselog/2008/547/ >>> , and the new versions should propagate to the opensolaris.org >>> web page soon. >>> -tdc >>> >>> >
LSARC/2008/550 - QT4 Framework
Darren J Moffat wrote: >> In /usr/include, which I believe is inconsistent, and wrong. > > Why ? /usr/include is where include files usually live and where they > are looked for by default. 1. How are we going to deliver multiple versions of QT? 2. If we do not deliver multiple versions of QT, and we overwrite the header files in /usr/include every time we uprev, we run the risk of breaking API and ABI. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
LSARC/2008/550 - QT4 Framework
Darren J Moffat wrote:
> The pkg-config file should be in /usr/lib/pkgconfig we already set
> precedence for this in other cases. I have no problem with providing
> multiple pkgconfig files under the path you gave but the canonical
> version of qt should have one in /usr/lib/pkgconfig
Which version of QT is the "canonical version of qt" ?
4.4.1 ? 4.5.0 ?
Trolltech makes no claims as to any of QT4's versions being "canonical".
>> Or, one can say --with-qt-include=${QTDIR}/include
>> --with-qt-libs=${QTDIR}/lib
>
> $QTDIR isn't defined in my environment.
>>> Is this the common layout on Linux based distributions where GNOME is
>>> considered the primary desktop rather than KDE ? What is they layout
>>> when KDE is the primary desktop ?
>>
>> SUSE organizes as /usr/lib/qt3 /usr/lib/qt4, etc
>
> where are the include files on SUSE ?
In /usr/include, which I believe is inconsistent, and wrong.
> Why is your layout better than the SUSE one ? What problems does it
> solve that their layout doesn't ?
The layout proposed here follows the layout established by the Perl ARC Case
PSARC/1999/192.
I don't know if it's "better" than Linux, I don't particularily consider Linux
a
benchmark for adjudicating the soundness of directory layouts, and I prefer
following established precedents which have been sanctioned and approved by the
ARCs.
>> It can't be Committed because [1] it doesn't really implement any
>> known Industry standard,
>
> That isn't the definition of committed.
http://opensolaris.org/os/community/arc/policies/interface-taxonomy/
It appears to be one of the attributes to be taken into consideration when
assigning a Committed stability level to an Interface, or a group of
Interfaces.
Given that QT does not implement a known Industry Standard, that's strike one
against Committed.
> > and [2] we don't control QT's Interface Stability level.
>
> Then what was all that text above about ? It can be Committed if the
> project team believes that the upstream behaves in a manner suitable.
> The text you provided indicates you do think that.
Considering the ABI Micro
Release Stability guarantee provided by Trolltech ASA, a
"Committed" Interface Stability Classification would have been
appropriate.
The project team does not believe that, nor do the ARC Case Documents imply
that
the project team believes that. The ARC Case documents clearly states that this
ABI stability guarantee is provided by Trolltech, and this guarantee only
applies to Micro releases.
Is an interface stability guarantee which is effective only for Micro releases
appropriate for "Committed" ? I do not believe that it is. We are saying that
"QT 4.4.1 will be ABI and API compatible with 4.4.3, but not with 4.5.0".
This does not qualify for "Committed". That's strike two against Committed.
--Stefan
--
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman at Sun.COM
Today's PSARC meeting - 20Q materials
All, PSARC is attempting to revise the 20 questions document down to something near 20 questions. I had volunteered to take a first crack at this. This proposal was sent to PSARC members and interns. There were some items of feedback. Attached is the original proposal, and the couple of comments (somewhat edited). -- - Rick Matthews email: Rick.Matthews at sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USAmain: +1(651) 554-1500 - -- next part -- An embedded and charset-unspecified text was scrubbed... Name: proposed20q.txt URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080827/c8797ee1/attachment.txt> -- next part -- An embedded and charset-unspecified text was scrubbed... Name: comments.txt URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080827/c8797ee1/attachment-0001.txt>
contract for Virtual Consoles to use 2000/517 audit interfaces and 2003/397
I've executed and recorded 2000/517-16 for PSARC/2006/591 Virtual Console to use the project private interfaces described in the prototype contract approved in 2003/397. 2003/397 and 2006/591 have a symlink to the executed contract. Gary..
No subject
console-core at sun.com Subject: contract for Virtual Consoles to use 2000/517 audit interfaces and 2003/397 I've executed and recorded 2000/517-16 for PSARC/2006/591 Virtual Console to use the project private interfaces described in the prototype contract approved in 2003/397. 2003/397 and 2006/591 have a symlink to the executed contract. Gary..
add top utility to SFW consolidation [PSARC/2008/533 FastTrack time out 08/26/2008]
This case was approved (again) at this morning's PSARC meeting. For the record, this case delivers /usr/bin/top with interface taxonomy uncommitted using package SUNWtop with a minor release binding. - Don
LSARC/2008/550 - QT4 Framework
Darren J Moffat wrote: > Consider that we only ship one version of GNOME and its libraries and > that is the OpenSolaris main desktop. We still ship two versions of the GTK library stack actually - GTK 1.x and GTK 2.x, since they are API & ABI incompatible. (GTK uses version numbers in a similar way to our taxonomy - incrementing the first for incompatible change, so if/when GTK 3.x arrives, we'll probably need to add a third.) GTK 1.x: /usr/sfw/lib/libgtk-1.2.so.0 GTK 2.x: /usr/lib/libgtk-x11-2.0.so.0 -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
PSARC Meeting Minutes - 08/27/2008
Minutes/Audio for PSARC 08/27/2008 are now available: - Open ARC Business: http://sac.sfbay/Archives/Minutes/PSARC/2008/20080827.html Open Audio: http://sac.sfbay/Archives/Minutes/PSARC/2008/20080827.arcbiz.open.mp3 Please contact me directly if you require any corrections/modifications to these minutes. Aarti
Perl Locale::gettext [LSARC/2008/535 FastTrack timeout 08/26/2008]
Thank you for all your help Joe Alan Coopersmith wrote: > This case was approved at LSARC today. > >
LSARC/2008/550 - QT4 Framework
Stefan Teleman wrote:
>
>
> Darren J Moffat wrote:
>> Does it really make sense to have all of QT hidden away in /usr/qt4 ?
>> I was expecting at least some things like include files or libraries
>> to be under /usr/include and /usr/lib respectively.
>>
>> My concern is how are autoconf, and the like, scripts that need to
>> find QT libraries and includes going to find it ? Are we expecting
>> that everyone will know to do something like this:
>>
>> ./configure --with-qt-include=/usr/qt4/4.4.1/include \
>> --with-qt-libs=/usr/qt4/4.4.1/lib/
>>
>> Is there no pkg-config .pc file for QT that can be placed in
>> /usr/lib/pkgconfig to help with this ?
>
> PKG_CONFIG_PATH can be set to
> /usr/qt4/4.4.1/lib/pkgconfig:${PKG_CONFIG_PATH}.
That assumes I already now where it is hidden, which kind of defeats the
part of point of pkgconfig
The pkg-config file should be in /usr/lib/pkgconfig we already set
precedence for this in other cases. I have no problem with providing
multiple pkgconfig files under the path you gave but the canonical
version of qt should have one in /usr/lib/pkgconfig
> Or, one can say --with-qt-include=${QTDIR}/include
> --with-qt-libs=${QTDIR}/lib
$QTDIR isn't defined in my environment.
>> Is this the common layout on Linux based distributions where GNOME is
>> considered the primary desktop rather than KDE ? What is they layout
>> when KDE is the primary desktop ?
>
> SUSE organizes as /usr/lib/qt3 /usr/lib/qt4, etc
where are the include files on SUSE ?
Why is your layout better than the SUSE one ? What problems does it
solve that their layout doesn't ?
> The question is: what happens when we want to include a newer version of
> QT (QT 4.5.0 is already out), which comes with newer and likeable
> features ? The two versions have to be able to coexist someohow, without
> creating conflicts.
That layout is okay for that but please provide the pkgconfig .pc file
in a place that is found by default for the recommended version
(currently 4.4.1).
>>> This Fasttrack proposes an overall "Uncommitted" Interface
>>> Stability Classification for QT4. Considering the ABI Micro
>>> Release Stability guarantee provided by Trolltech ASA, a
>>> "Committed" Interface Stability Classification would have been
>>> appropriate. However, QT4's dependency on
>>> External/Evolving/Uncommitted Interfaces makes an overall
>>> "Committed" Interface Classification inaproppriate.
>>
>> That doesn't follow. Just because you have lower classified
>> dependencies doesn't mean you can't be higher than them. That is the
>> definition of what we do in ARC. Everything is built on something of
>> a lower classification at some level. So if this really could be
>> Committed other than for the incorrect assumption on the dependencies
>> it should be Committed.
>
> It can't be Committed because [1] it doesn't really implement any known
> Industry standard,
That isn't the definition of committed.
> and [2] we don't control QT's Interface Stability level.
Then what was all that text above about ? It can be Committed if the
project team believes that the upstream behaves in a manner suitable.
The text you provided indicates you do think that.
--
Darren J Moffat
OpenARC Serviceability Guidelines [LSARC/2008/547 FastTrack timeout 09/02/2008]
Tom, Yesterday during LSARC you stated something about the intent of these guidelines were not necessarily at FOSS projects. Is that correct? If so then perhaps a short preamble is required for the guidelines. Thanks, John On Tue, 2008-08-26 at 12:11, Tom Childers wrote: > Here is an updated version of the guidelines document for this case, > incorporating the feedback so far. > > The doc is available at > http://www.opensolaris.org/os/community/arc/caselog/2008/547/ > , and the new versions should propagate to the opensolaris.org web > page soon. > -tdc > >
/PSARC/2008/482 - NWAM Phase 0.5 (picea)
> John Fischer writes: > > Having received no comment on this opinion and a week > > has passed I am going to forward this to SAC. > > There are two contracts on the way. I don't think they affect much > (one for use of libbsm and the other between the GUI and ON teams > within the project), but as a procedural bit, I think they should be > there before the case is closed. As the SUPPLIER for the audit interfaces (and I expect to do the contract and move it through), I have no issues with the architecture of the case moving on to closing out without the contract in place. I still owe Jim code review and doing a contract. I'll do that as it fits into my schedule, likely in the next couple days. Note that the RM for SUPPLIER will be on holiday and not available after today. Gary..
add top utility to SFW consolidation [PSARC/2008/533 FastTrack time out 08/26/2008]
Don Cragun wrote: > Since all open issues have been resolved and there have been no > additional comments for the last six days, I'm marking this case > closed approved. I was still waiting on a proper spec as I had asked for so I'm very surprised to see this as closed. The reason I hadn't commented was because there is no spec to comment on, just a copy of the top man page. What is the release binding, interface taxonomy, package name etc. None of that is covered in the man page. Please mark this case as waiting need spec and provide the above information. None of that was in the original spec either. -- Darren J Moffat
/PSARC/2008/482 - NWAM Phase 0.5 (picea)
All, Having received no comment on this opinion and a week has passed I am going to forward this to SAC. Thanks, John On Wed, 2008-08-20 at 11:49, John Fischer wrote: > All, > > Here is the draft opinion for the NWAM case that > was reviewed last week. The case directory contains > the attached text version and an nroff version. > Feedback welcomed. > > Thanks, > > John > >
Gkrellm for OpenSolaris [LSARC/2008/513 FastTrack timeout 08/19/2008]
Hi, all I am resetting the time out for this case to be August 29th. Any issues please send an email before then. Thanks --Irene Brian Cameron wrote: > > Henry: > > Much more clear. Thanks. > > Brian > > >> Brian Cameron ??: >>> >>> Henry: >>> >>> The one pager does not mention the ~/.gkrellm2/plugins-gkrellmd/ >>> interface, nor does it mention that end users can install their own >>> plugins. >>> >>> In section 4.1 you say: >>> >>>And in order to make install plugin, you should be root, >>>and ensure the plugin will not add additional security issue. >>> >>> The above seems a bit misleading since you can also install plugins >>> as users. You don't need to be root. >> >> That make sense, I added the content on the end-user plugin supports. >>> >>> In section 4.11, you say >>> >>> This application uses OpenSSL, and support plugins, it may >>> cause >>> some security concern, >>> >>> It isn't clear if you are saying that there is some security concern >>> with OpenSSL or plugins, or both. Is the security concern the same >>> or different for these two things? >>> >>> but generally all data transfered through the connection >>> is the system usage status information, and not very >>> confidential, >>> >>> It is probably reasonable to say this for the default plugins, but >>> I'd think that an end user could install plugins that do not follow >>> this general rule. >>> >>> addtionally in order to make the network connection more >>> secure, >>> this application is using SSH and some configuration on IP/port >>> to use, >>> >>> Do you mean to say "this application uses SSH and allows the sysadmin >>> to specify which IP/port to use via configuration." Are you >>> suggesting >>> that being able to configure the IP/port adds security? You misspell >>> "Additionally". >>> >>> In general I find section 4.11 a little hard to read since it is one >>> long sentence. >> I updated the one-pager, hope this make things more clear. >> >>> >>> Brian >>> >>> I would summary the discussion below. 1, The battery support on Solaris: I investigated 2 solution, one is the patch wrote by David, but this patch is using acpidrv.h and /dev/acpidrv which are not on Solaris now, the other solution is using HAL, I think this is a solution we can use. So I am implementing to use HAL/Dbus for the battery information. 2, SSL certification authentication: I checked the bugzilla, and no category for GKrellM, I sent a mail to the maintainer on this issue. I am discussing with him on how to fix this problem.. 3, Security impact: Add some content to describe the possible impaction. Attachment is the updated one-pager.. Thanks, Henry Henry Zhang ??: > Hi Darren, > > Thanks, I will file a bug on this issue... > > Regards, > Henry > > Darren J Moffat ??: >> I see from the code that it is passing SSL_VERIFY_NONE to >> SSL_CTX_set_verify() >> >> From the man page: >> >> >> SSL_VERIFY_NONE >> Server mode: the server will not send a client >> certificate request to the client, so the client will >> not send a certificate. >> >> Client mode: if not using an anonymous cipher (by >> default disabled), the server will send a certificate >> which will be checked. The result of the certificate >> verification process can be checked after the TLS/SSL >> handshake using the SSL_get_verify_result(3) function. >> The handshake will be continued regardless of the >> verification result. >> >> >> This is the answer for the case. Personally I'm not happy with >> this however it is what gkrellm does and it answers my question. >> I would like the project team to file a bug upstream (if there >> isn't one already) to provide functionality to actually verify >> the server's SSL/TLS certificate. >> >> -- >> Darren J Moffat >>> >
PSARC/2008/543 - Python 2.5
All, This case was approved today at PSARC. John On Sat, 2008-08-23 at 20:11, Laszlo (Laca) Peter wrote: > On Sat, 2008-08-23 at 00:29 -0700, Danek Duvall wrote: > > > > Perhaps there should be a requirement for 2.5 modules? Or just make > > > > both required for the time being? > > > > > > That would make sense, at least until 2.4 is Obsolete, but I'm not > > > sure how to enforce it. > > > > By stating that requirement in this case, setting a precedent that future > > cases will have to follow. Enforcement will be up to the ARC (to point the > > rule out to teams that might not have gotten the message) and the c-teams > > (to make sure that they don't actually integrate without having support for > > both versions). > > Okay, I'll update the proposal to state that it is a requirement to > deliver python modules for both (or all) versions of python and also > 32-bit and 64-bit variants if applicable. > > Laca >
PSARC/2008/542 - libffi - Foreign Function Interface library
All, This case was approved at PSARC business today. Thanks, John On Tue, 2008-08-26 at 20:37, Laszlo (Laca) Peter wrote: > That worked, thanks Brian and Google :) > So the dependency on libgcc_s.so.1 is not necessary and will be > removed from the imported interfaces table. > > Laca > > On Tue, 2008-08-26 at 22:26 +0100, Brian Ruthven - Solaris Network > Sustaining - Sun UK wrote: > > Can't it be eliminated with something like -s?tatic-libgcc ? At least > > that's what Google tells me I can do :-) > > Or is it specifically required that the libgcc_s library is external > > (i.e. dynamically loaded) rather than statically linked in at compile time? > > > > Brian > > > > Laszlo (Laca) Peter wrote: > > > On Fri, 2008-08-22 at 17:17 -0700, Danek Duvall wrote: > > > > > >>> 2.2 Imported Interfaces > > >>> > > >>> Interface Classification Comments > > >>> - -- > > >>> -- > > >>> libgcc_s.so.1 VolatilePSARC/2004/742 > > >>> > > >> Couldn't this be eliminated by using the Studio compiler? > > >> > > > > > > It would, but libffi contains ASM code that doesn't build with > > > Sun Studio. It may be possible to build it with a future > > > version of Sun Studio. > > > ? > > > > > >> Or does Python require gcc? > > >> > > > > > > No. > > > > > > Laca > > > > > > >
add top utility to SFW consolidation [PSARC/2008/533 FastTrack time out 08/26/2008]
>Date: Wed, 27 Aug 2008 10:24:24 +0100 >From: Darren J Moffat > >Don Cragun wrote: >> Since all open issues have been resolved and there have been no >> additional comments for the last six days, I'm marking this case >> closed approved. > >I was still waiting on a proper spec as I had asked for so I'm very >surprised to see this as closed. The reason I hadn't commented was >because there is no spec to comment on, just a copy of the top man page. > >What is the release binding, interface taxonomy, package name etc. None >of that is covered in the man page. Quoting from the first message sent to this case's mail log: "The project team is requesting a minor release binding." If you were concerned that the interface taxonomy and package name were not covered, I would have expected you to request that information before the case timed out; I see no request for that information in the mail log. (It is also interesting to note that there is no interface taxonomy listed on the prstat(1M) man page.) I will get the interface taxonomy and package name from the project team later this morning. In the interest of not playing fetch a rock, what other information are you expecting when you say "etc."? - Don > >Please mark this case as waiting need spec and provide the above >information. None of that was in the original spec either. > >-- >Darren J Moffat
LSARC/2008/550 - QT4 Framework
Laszlo (Laca) Peter wrote:
> On Tue, 2008-08-26 at 14:35 -0400, Stefan Teleman wrote:
>>> Is there no pkg-config .pc file for QT that can be placed in
>>> /usr/lib/pkgconfig to help with this ?
>> PKG_CONFIG_PATH can be set to /usr/qt4/4.4.1/lib/pkgconfig:
>> ${PKG_CONFIG_PATH}.
>>
>> Or, one can say --with-qt-include=${QTDIR}/include --with-qt-libs=
>> ${QTDIR}/lib
>
> The problem is that for people who naively try to build Qt apps
> on Solaris, it will seem that there is no Qt on Solaris.
> It would be really nice to symlink the pc files of the latest
> version to /usr/lib/pkgconfig.
Oh, that is easy to do. I will alter the Case to reflect this change + Alan
Coopersmith's Xrender/XrandR Case number changes.
--Stefan
--
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman at Sun.COM
