Integrate libm17n and scim-m17n to Solaris [PSARC/2008/624 FastTrack timeout 10/13/2008]
Hi, guys, Since we have reached the duedate, and no negative comments, I'd like to close this case as "closed approved fast-track 10/13/2008". Thank you very much for the support! Regards, Yong Sun ??: > I just updated the one-pager to include m17n-im-config-0.9.0 (in > LGPLv2.1), please refer to the casedir for these minor changes. > > Regards, > > Yong Young Sun wrote: >> Template Version: @(#)sac_nextcase %I% %G% SMI >> This information is Copyright 2008 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> Integrate libm17n and scim-m17n to Solaris >> 1.2. Name of Document Author/Supplier: >> Author: Yong Sun >> 1.3 Date of This Document: >> 06 October, 2008 >> >> 2. Project Summary >>2.1. Project Description: >> This project is to integrate libm17n and scim-m17n to Solaris >> Nevada >> and OpenSolaris. >> >> COMPONENT VERSION LICENSE TERMS >> >> m17n-lib-core 1.5.2 LGPLv2.1 >> m17n-db 1.5.2 LGPLv2.1 >> m17n-contrib1.1.7 LGPLv2.1 >> scim-m17n 0.2.2 GPLv2 >> >>2.2. Risks and Assumptions: >> We would not ship the GUI interfaces in m17n library, scine >> it is >> not adopted widely, and has many other dependencies like >> fribidi and libotf. >> 4. Technical Description >>4.1. Details: >> m17n (www.m17n.org) is a library written in ANSI-C, to >> supports various >> aspects of multilingualization (m17n) for linux/unix >> applications, it provides following features: >> >> * M-Text: string with properties which could be nested or >> overlapped >> * character rendering engine: supports CTL and OpenType (by >> libotf) >> * input methods: www.m17n.org/m17n-lib-en/support_input_sum.html >> >> This project is to leverage the input methods in m17n and the >> scim adapter (scim-m17n) to provide more input methods on >> SCIM stack. >> 4.2. Bug/RFE Number(s): >> None >> 4.3. In Scope: >> N/A >> >> 4.4. Out of Scope: >> The GUI supports in m17n is not delivered. >> 4.5. Interfaces: >> >> INTERFACE NAME STABILITYNOTE >> >> >> /usr/bin/m17n-config Uncommitted compilation and >> linking flags >> /usr/bin/m17n-conv Uncommitted encoding conversion >> utility >> /usr/bin/m17n-db Uncommitted version and location >> information of >> database files >> >> /usr/lib/libm17n-core.so Uncommitted M-Text and other core >> APIs >> /usr/lib/libm17n.soUncommitted IM, language data APIs >> /usr/lib/libm17n-flt.soUncommitted font layout table APIs >> /usr/lib/libmimx-anthy.so Uncommitted IM extension of libanthy >> >> /usr/share/m17n/icons/*Uncommitted icons for languages >> and IMs >> /usr/share/m17n/*.mim Uncommitted input methods >> /usr/share/m17n/*.map Uncommitted charset maps >> /usr/share/m17n/*.flt Uncommitted font layout tables >> /usr/share/m17n/*.lnm Uncommitted localized language names >> /usr/share/m17n/*.tab Uncommitted various tables from >> UNIDATA >> /usr/share/m17n/*.tbl Uncommitted various configure tables >> >> /usr/lib/scim-1.0/1.4.0/ Uncommitted scim engine for m17n IMs >> IMEngines/m17n.so >> >> 4.6. Doc Impact: >> None >> 4.7. Admin/Config Impact: >> None >> 4.8. HA Impact: >> None >> 4.9. I18N/L10N Impact: >> None >> >> 4.10. Packaging & Delivery: >> SUNWm17n-lib-core >> SUNWm17n-lib-core-devel >> SUNWm17n-db >> SUNWm17n-db-devel >> SUNWm17n-contrib >> SUNWscim-m17n >> >> 4.11. Security Impact: >> None. >> 4.12. Dependencies: >> None. >> >> 5. Reference Documents: >>1). m17n OverView >> http://www.m17n.org/m17n-lib-en/overview.html >> >>2). SCIM and IMEngines >> http://www.scim-im.org PSARC 2008/418 Integrate SCIM >> to Solaris >> >> 6. Resources and Schedule >> 6.4. Steering Committee requested information >>6.4.1. Consolidation C-team Name: >> Globalization >> 6.5. ARC review type: FastTrack >> 6.6. ARC Exposure: open >> >> >
PAM prompt configuration enhancement for the pam_pkcs11 module [PSARC/2008/635 Self Review]
Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: PAM prompt configuration enhancement for the pam_pkcs11 module 1.2. Name of Document Author/Supplier: Author: HuieYing Lee 1.3 Date of This Document: 15 October, 2008 4. Technical Description Update to PSARC/2006/283 Certificate & PKCS#11 PAM module. To port the pam_pkcs11 module to OpenSolaris, we removed the "Smart card" keywords from the PAM prompt messages and updated the messages to be more generic because the original OpenSC/pam_pkcs11 module incorrectly assumed that all PKCS#11 tokens are smartcards. After we contributed these prompt message changes back to the upstream communtity (opensc.org) a couple of weeks ago, they requested that we make further changes to allow the PAM prompt messages configurable. In this enhancement, a new "token_type" parameter is added to the pam_pkcs11.conf configuration file and its value will be used in the user prompt messages. This enhancement request has been implemented and integrated into the upstream community on Oct/14. To keep the OpenSolaris source in sync with the upstream OpenSC community, we would like to integrate the change to OpenSolaris as well. For more information, see the attached diffs to the default pam_pkcs11.conf below. *** pam_pkcs11.conf.origTue Oct 14 14:34:29 2008 --- pam_pkcs11.conf Tue Oct 14 14:38:20 2008 *** *** 75,80 --- 75,84 # cert_policy = ca,signature; cert_policy = signature; + # What kind of token? + # The value of the token_type parameter will be used in the user prompt + # messages. The default value is "Smart card". + token_type = "Secure token"; } # Which mappers ( Cert to login ) to use? 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: SFW 6.5. ARC review type: Automatic 6.6. ARC Exposure: open
GNU Multiple Precision Library [GNU MP] [LSARC/2008/634 FastTrack time
> This project proposes to integrate the GNU Multiple
> Precision
> library (GNU MP) into a Patch release of Solaris.
You don't specify what changed since 2008/166.
> /usr/lib/libgmp.so.3.4.2
> /usr/lib/${MACH64}/libgmp.so.3.4.2
You mention a 32bit and 64bit version, but no platform specific version. If
performance is wanted, there should be a different version for ultrasparc12,
ultrasparc34, ultrasparcT1 (the default for sparc is to use FP, which is a bad
idea there), etc. GMP provides a different assembler version of the core
routines for these platforms. Ideally there would be some filtering linker
technique to split only the different pieces and not require users to add
something with $PLATFORM to their rpath, but that may be too much work.
If you only want gmp for features, what you propose should be fine (still, take
care of what implementation you chose, as the case of T1 processors shows).
> The version of GNU MP [4.2.2] proposed for
> r Integration
Isn't 4.2.4 out, with several bug fixes?
> By default, GNU MP installs its header files under
> r /usr/include.
> We propose changing this default installation
> n location to a more
> suitable /usr/include/gmp, for the purpose of
> f avoiding namespace
> pollution in /usr/include.
Argh, very bad idea. Or at least put those that don't conflict in /usr/include.
> libmp.so.3.1.11 is the C wrapper providing the BSD
> D MP
> Compatibility API Layer. This library does not
> t implement any
> new functionality in GNU MP; its purpose is
> s restricted to API
> compatibility.
This compatibility layer was disabled in the previous ARC case, and its file
mp.h is the only thing that conflicts with existing solaris files.
> provides specific options for handling temporary
> y memory allocations:
>
> --enable-alloca=
>
> The allowed options are:
>
> --enable-alloca=alloca
> --enable-alloca=malloc-reentrant
> --enable-alloca=malloc-notreentrant
>
> This option is particularily relevant when the
> e consumer of the
> GNU MP interfaces must allocate very large temporary
> y objects.
> For the purposes of this Integration, GNU MP will be
> e built with
> the --enable-alloca=malloc-reentrant option.
Why? Enabling alloca makes small allocations much faster and goes back to
malloc-reentrant for large allocations (since 4.2.0 I believe).
> This Integration of GNU MP will also enable the BSD
> D MP
> compatibility layer library [libmp.so.3.1.11]:
>
> --enable-mpbsd
Is that really necessary? For old applications, there is already an MP library
in solaris, and new ones should use gmp. So having both (incompatible?)
implementations complicates things, although it does not hurt too much as long
as this is not used as a reason for moving perfectly fine headers (gmp.h and
gmpxx.h) in some hidden directory. What is your opinion on handling these 2
versions?
> GNU MP imports interfaces from the Standard C
> C Library and the
> Standard Math Library. In addition, the C++ GNU MP
> P Library
> imports interfaces from the C++ run-time Library
> y [libCrun.so.1]
> and from the Standard C++ Library [libCstd.so.1].
You mean this will use Cstd and not the apache stdcxx?
> [6] /shared/sac/PSARC/2007/166
Isn't that 2008/166 ? That's what I can see in the old emails from february.
--
This message posted from opensolaris.org
LARC meeting summary, Tue, 7 Oct
Thank you Tom, We would work to provide you with info requested. -Ivan Tom Childers wrote: > Nasser and Ivan, > > We discussed your case as the LSARC meeting this morning, and don't > believe you need to schedule time for a discussion in the meeting. Your > materials look very straightforward. We'll complete the fast track > review as soon as you provide the interfaces specs we need. > > As Aniruddh suggested, please add Chime as an imported interface, with a > reference to the source URL for the project. I assume Chime is an > Evolving interface. Then add it a second time as an exported interface, > classified as Private. Since it imports the DTrace API, add the DTrace > API (/usr/lib/java/dtrace.jar) to the imported interfaces, with > Committed as the classification, and PSARC/2006/054 as the source. Along > with your NBM file, you should have 4 entries, 2 imported and 2 exported. > > The interfaces section of your one-pager needs to be formatted into > three columns, as shown in the template. Normally, we would have a "20 > questions" document that would specify this. See > http://www.opensolaris.org/os/community/arc/handbook/questionnaire/. > item 13 for an interfaces table. > > Thanks, > > Tom Childers > Sr. Staff Engineer > Sun Microsystems, Inc. > SOA/Business Integration Engineering > > On Oct 14, 2008, at 8:43 AM, Ivan Vlasyuk wrote: > >> Aarti, >> Please include this on the next week LSARC team meeting. >> I believe we will settle all the paperwork by end of this week. >> -Ivan >> >> Aniruddh Dikhit wrote: >>> Nasser Nouri wrote: Hello Aniruddh, The DTrace GUI utilizes the DTrace Java API indirectly via Chime. I can update the one-pager and describe how the Chime's methods are called by DTrace GUI top component. Currently, it only calls two methods from the Chime JAR file in order to instantiate Chime component. Chime is fully integrated with NetBeans DTrace GUI Plug in. Users are not required to download Chime separately in order to use NetBeans DTrace GUI. Basically, Chime is a component of NetBeans DTrace GUI. I would like to know whether we need to submit a separate one-pager for Chime or it can be included with one-pager for DTrace GUI. >>> You can still import chime as a software component and call it out as >>> a component your >>> software depends on. You can export that as a private interface with >>> apt classification. >>> Tom if you have any other suggestion please let me know. I'll >>> announce the fasttrack tomorrow >>> and shall set the 1-week timer on this project. >>> thanks >>> -Aniruddh Ivan, probably, someone from your group should help me to describe what API NetBeans uses to interface with plug-ins or external clusters such as DTrace GUI! Thanks, __Nasser >
Kerberos PKINIT [PSARC/2008/631 FastTrack timeout 10/17/2008]
On Mon, 2008-10-13 at 18:11 -0700, Kais Belgaied wrote: > > > > * New kinit(1) options: > > > > -X attribute[=value] > > specify a pre-authentication attribute and value to be > > passed to pre-authentication plugins. The acceptable > > attribute and value values vary from pre-authentication > > plugin to plugin. This option may be specified multi- > > ple times to specify multiple attributes. If no value > > is specified, it is assumed to be "yes". > > > > The following attributes are recognized by the OpenSSL pkinit > > pre-authentication mechanism: > > X509_user_identity=URI > > Specify where to find user's X509 identity information. > > > > Valid URI types are FILE, DIR, PKCS11, PKCS12, and ENV. > > See PKINIT URI Types section for more details. > > > > X509_anchors=URI > > Specify where to find trusted X509 anchor information. > > > > Valid URI types are FILE and DIR. > > See PKINIT URI Types section for more details. > > > > flag_RSA_PROTOCOL[=yes] > > Specify use of RSA, rather than the default > > Diffie-Hellman protocol. > > > Does OpenSolaris have any latitude in changing the attributes or do they > need to be kept verbatim as > they come from MIT code drops? We have latitude but generally we like to remain as compatible with upstream as possible. > If we do, then the choice of boolean flag_RSA_PROTOCOL[=yes] excluded other > key exchange algorithms, such as ECC. As PKINIT (RFC 4556) doesn't support ECC key exchange I don't see an immediate need for this and is not worth (in my opinion) breaking MIT compatibility for it now. I should note that this config file option is "Volatile". -Mark
PAM prompt configuration enhancement for the pam_pkcs11 module [PSARC/2008/635 Self Review]
> Update to PSARC/2006/283 Certificate & PKCS#11 PAM module. +1 if needed. Gary..
Dante: A Socks server and client implementation [LSARC/2008/632 timeout 10/22/2008]
James Gates writes: > I'm sponsoring this case on behalf of Mayuresh Nirhali. Timeout is set > for 10/22/2008. Attached is the one_pager and FOSS checklist. ARC review > is required on account of their being configuration files in /etc and > setuid/setgid privileged binaries. Yay! > Dante is a circuit-level firewall/proxy that can be used to provide > convenient and secure network connectivity to a wide range of hosts > while requiring only the server Dante runs on to have external > network connectivity. Are there follow-on projects to SOCKSify applications? > Are there any setuid/setgid privileged binaries in the project? > [X] Yes - ARC review required [...] > > If yes then are the setuid/setgid privileges handled by the use of > roles? > [ ] Yes > [X] No - ARC review required If you're using SMF for the service, then what's the need for setuid/setgid? > 3.4.3 Auditing > (see http://opensolaris.org/os/community/arc/policies/audit-policy/ for > details) > (see http://opensolaris.org/os/community/arc/caselog/2003/397 for > details) > Does this component contain administrative or security enforcing > software? > [ ] Yes - ARC review required > [X] No - continue to next section (section 3.4.4) Is that answer right? The SOCKS server *does* have a facility to authenticate users and enforce security, doesn't it? I don't think this has auditing capabilities. > 3.4.4 Authentication > (see http://opensolaris.org/os/community/arc/policies/PAM/) > Do the components contain any authentication code? > [ ] Yes > [X] No - continue to next section (section 3.4.5) The normal Dante server does. You set it up with the "method:" keyword. > 3.4.5 Passwords > (see > http://opensolaris.org/os/community/arc/bestpractices/passwords-cli/ and > > http://opensolaris.org/os/community/arc/bestpractices/passwords-files/ for > details) > Do any of the components for the project deal with passwords? > [ ] Yes > [X] No - continue to next section (section 3.4.6) Yes; both client and server can use passwords and user names. > Do network services for the project make decisions based upon user, > host or > service identities? > [ ] Yes - explain below > [X] No > [ ] N/A Yes, they can do this. > Do the components make use of secret information during authentication > and/or > authorization? > [ ] Yes - explain below > [X] No > [ ] N/A Yes. > | 1 | libdsocks.so| Unstable/Uncommitted | SOCKS daemon > library | > | > |-+--| > | 2 | libsocks.so | Unstable/Uncommitted | SOCKS library > | Given the age and stability of this project, and the way in which SOCKSified applications depend on them, I don't think the above is right. Plus, "Unstable" isn't a commitment level. I suspect that libdsocks.so is actually Project Private (nothing outside of Dante should use it), and that libsocks.so is a Committed interface (it's not going to change incompatibly; it's set by the BSD sockets interface). > Dante is a third party Socks server and client implementation. The > current version (1.1.19) is stable and it was released in > January 2006. Since then, there has been no releases of this product. That conflicts with the interface stability. If it's stable, then let's make it stable for our customers as well. > SMF service for Dante SOCKS server will be added under network category > as > network/sockd. The package will add the manifest file and SMF method as > below, Nit: please use network/socks rather than network/sockd. We're trying to avoid 'd' for 'daemon' in the names of SMF FMRIs. -- 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
Derailing PSARC/2008/628 Interrupt Resource Management
Roamer since this is a full case now, the procedure is to add the comments to the issues file (for internal contributors). Kais. On 10/10/08 19:14, Yunsong (Roamer) Lu wrote: > A few more concerns about the IRM proposed interfaces. > > 1. When the material talks about current interface limitation, 4.1.2, > why it's a problem to allow a driver to get more that *2* MSI-X? Those > integrated device drivers should be prepared that it can not get any > MSI-X interrupt vector, and it might try the legacy INTX instead. So > it should not be a problem even all MSI-X vectors have been given to > those attached drivers. Late-attached drivers will just use legacy > INTX interrupts. The justification for current *hard-coded* limitation > doesn't make sense. > > 2. How the IRM framework decide to decrease the number of interrupt > vectors that have been given to a driver? 4.2.1 talk about how driver > participate the IRM interfaces, but it's obscure how the framework can > wisely move interrupt resources around drivers. > > 3. How the IRM framework make *wise* decision about which driver can > take more interrupt vectors than others? For example, when you have a > 10GbE NIC and a 1GbE NIC in the box, both drivers ask for 16 vectors > when you don't have enough vectors left. To give the same amount of > interrupt vectors to two driver instances are unreasonable. As part of > Crossbow project, hardware resources are allocated depending on the > real link speed and bandwidth need. But as the low level I/O > framework, IRM don't have knowledge about those information. How do > you prove that your "management" is reasonable? > > 4. What's the perimeter of IRM? In a virtualized environment, > interrupts might have been bound to CPUs in an exclusive zone or a > guest domain, when IRM asks such interrupt vectors back from the > driver, who will take care of the interrupt re-targeting? It's out of > driver's control, and I can not find any relevant information from > this document. > > Thanks, > > Roamer
IBTF IO Memory [PSARC/2008/630 FastTrack timeout 10/17/2008]
Minor nit: materials/ibc_operations_t.9s Add ibc_alloc_io_mem(9E) and ibt_alloc_io_mem(9F) to the "See also:" +1 -- - 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 -
IBTF IO Memory [PSARC/2008/630 FastTrack timeout 10/17/2008]
- Case boundary question: since this marks a flag day for both TI and
CI, can you list the components
that are affected by this flag day?
- I am not clear on the consumer side of this new interface: What
prompts a ULP to start using this interface?
Is it expected to attempt ibt_alloc_io_mem() until it exhausts all
resources?
It would be easier to assess the completeness and the usefulness of
the TI if you either extended the case's scope
to include at least the changes on one transport consumer or gave a
real example thereof.
- mi_ibt_version seems to be an enumeration of apparently mutually
exclusive values IBTI_V{1,2,3}
yet the definition suggests a combination of independent (discrete)
capabilities
(FMR support, DMA wrapper support, etc.)
. Is there any consumer of this interface that uses DMA wapper but
not FMR?
. For future evolution, is the mi_ibt_version always intended to
express a monotonically increasing set
of capabilities (capabs of V(n+1) includes all capabs of N(n)) ?
Basically I'm trying to see if information of different nature if
being encoded in the same field. Without slipping
in a design discussion you should consider if two fileds are more
appropriate: 1 version (number or enum) and one capabs (bitmask).
- Under what condition can the caller of
ibt_alloc_io_mem()/ibt_free_io_mem() expect the following error
to be returned?
59 IBT_MR_ACCESS_REQ_INVALID Invalid Access Control Specified.
60 Remote Write or Remote Atomic access is
61 requested without specifying Local
Write.
- in ibc_alloc_io_mem.9e
these two sections are in conflict:
11 ibt_status_t prefix_ibc_alloc_io_mem(ibc_hca_hdl_t hca_hdl,
12 size_t size, ibt_mr_flags_t mr_flag, caddr_t *kaddrp,
13 ibc_mem_alloc_hdl_t *mem_alloc_hdl);
and
23 hca_hdl IBTF channel Interface (TI) HCA Handle previously
obtained
24 by calling ibt_open_hca(9F).
25
Kais.
On 10/10/08 11:04, Ted Kim wrote:
> Template Version: @(#)sac_nextcase %I% %G% SMI
> This information is Copyright 2008 Sun Microsystems
> 1. Introduction
> 1.1. Project/Component Working Name:
>IBTF IO Memory
> 1.2. Name of Document Author/Supplier:
>Author: Lida HornI
> 1.3 Date of This Document:
> 10 October, 2008
> 4. Technical Description
>
> A. Background
>
> The DDI distinguishes between different "types" of memory. Memory from
> ddi_dma_mem_alloc(9F) is usable for DMA and takes into account various
> factors such alignment and other device attributes. Memory from
> kmem_(z)alloc is not guaranteed to be usable for DMA, though most of
> the time it does work for that purpose, because of the capability of
> modern platforms. Nevertheless, there is value in maintaining these
> DDI distinctions, especially when considering certain platform issues
> such as memory DR.
>
> In the context of InfiniBand, registered memory is the target of DMA
> operations. This case introduces new InfiniBand related interfaces
> analogous to the ddi_dma_mem_alloc family of functions to IBTF
> (InfiniBand Transport Framework, PSARC/2002/132 and follow-on
> cases). This addition will help the InfiniBand stack maintain the
> proper DDI memory distinctions important for certain types of
> platforms.
>
>
> B. Proposal
>
> The proposal is to make additions to the IBTF Channel and Transport
> interfaces. The functionality added to the Transport Interface (TI) is
> used by the ULPs to allocate memory suitable for DMA and IB memory
> registration. In turn, the framework uses new entry points in the
> Channel Interface (CI) to request memory allocation from the
> underlying HCA driver. These interfaces are basically a wrapper for
> DDI functions which on the one hand abstract away HCA device specific
> details at the ULP level, but at the same time allow for the HCA
> driver to adjust the memory attributes (alignment, etc.) as necessary
> for efficiency.
>
> These additions include an IBTF ABI change, so this case also marks an
> internal flag day, incrementing our interface version numbers for both
> the TI and CI as noted below.
>
>
> All interface additions and changes in this proposal have a
> micro/patch binding.
>
> Transport Interface (ON Consolidation Private):
>
> ibt_alloc_io_mem() - Allocates DMA memory (at the transport level)
> ibt_free_io_mem() - Deallocates DMA memory
> IBTI_V3 - TI version change
>
> Channel Interface (ON Consolidation Private):
>
> ibc_alloc_io_mem() - Allocates DMA memory (at the HCA driver level)
> ibc_free_io_mem() - Deallocates DMA memory
> IBCI_V3 - CI version change
>
>
> C. Summary of Changes by man page
>
> See materials directory for copies of man pages. Modified man pages
> have change bars in the left margin.
>
> ibci.9 - modfied (new CI entry points added)
>
> ibc_alloc_io_mem.9e - new (alloc & free CI entry points)
>
>
IBTF IO Memory [PSARC/2008/630 FastTrack timeout 10/17/2008]
Okay, that's a trivial edit, we will do it no problem. Rick Matthews wrote: > Minor nit: >materials/ibc_operations_t.9s > >Add ibc_alloc_io_mem(9E) and ibt_alloc_io_mem(9F) to the "See also:" > > +1 -- Ted H. Kim Sun Microsystems, Inc. ted.kim at sun.com 222 North Sepulveda Blvd., 10th Floor (310) 341-1116 El Segundo, CA 90245 (310) 341-1120 FAX
IBTF IO Memory [PSARC/2008/630 FastTrack timeout 10/17/2008]
Kais,
Kais Belgaied wrote:
> - Case boundary question: since this marks a flag day for both TI and
> CI, can you list the components
> that are affected by this flag day?
Most of the IB modules in ON -
framework: IBTL
IB ULPs (TI): IPonIB, SDP, NFS/RDMA, uDAPL
HCA Drivers (CI): Tavor, Hermon
> - I am not clear on the consumer side of this new interface: What
> prompts a ULP to start using this interface?
> Is it expected to attempt ibt_alloc_io_mem() until it exhausts all
> resources?
> It would be easier to assess the completeness and the usefulness of the
> TI if you either extended the case's scope
> to include at least the changes on one transport consumer or gave a
> real example thereof.
We are in the process of fixing bugs in certain IB ULPs to
be good citizens in big SPARC platforms with memory DR where
we have to be careful about what is in/out of the cage.
The current plan for ULP usage (i.e. TI usage) is related
to this motivation.
> - mi_ibt_version seems to be an enumeration of apparently mutually
> exclusive values IBTI_V{1,2,3}
> yet the definition suggests a combination of independent (discrete)
> capabilities
> (FMR support, DMA wrapper support, etc.)
The features are examples of what was included at each version change.
More discussion of the relationship between ABI and features below ...
> . Is there any consumer of this interface that uses DMA wapper but
> not FMR?
Well to be honest FMR in the current form turned out to be a failure.
So no one uses FMR in ON right now.
But I think more generally what is going to happen is that
the features will be used independently of each other,
since they are generally not related to each other.
> . For future evolution, is the mi_ibt_version always intended to
> express a monotonically increasing set
>of capabilities (capabs of V(n+1) includes all capabs of N(n)) ?
Yes, that is the intent, but it is not guaranteed. However,
as you might imagine, it would involve a great deal of
discussion/agreement to remove anything and the ARC would be
in the loop.
> Basically I'm trying to see if information of different nature if
> being encoded in the same field. Without slipping
> in a design discussion you should consider if two fileds are more
> appropriate: 1 version (number or enum) and one capabs (bitmask).
There are in fact capability bitmasks elsewhere.
In IB there are a number of optional features. So the bitmasks
generally are for saying you have these optional features.
But the version number is more an ABI thing, and it is mistake
to conflate the too, though the reason we have to change ABI
is that new features demand more fields in the structs, etc.
> - Under what condition can the caller of
> ibt_alloc_io_mem()/ibt_free_io_mem() expect the following error
> to be returned?
> 59 IBT_MR_ACCESS_REQ_INVALID Invalid Access Control Specified.
> 60 Remote Write or Remote Atomic access is
> 61 requested without specifying Local
> Write.
It's a mistake and that text should be removed. That's only
something that could happen during an IB memory registration.
We will correct it.
> - in ibc_alloc_io_mem.9e
> these two sections are in conflict:
> 11 ibt_status_t prefix_ibc_alloc_io_mem(ibc_hca_hdl_t hca_hdl,
> 12 size_t size, ibt_mr_flags_t mr_flag, caddr_t *kaddrp,
> 13 ibc_mem_alloc_hdl_t *mem_alloc_hdl);
> and
> 23 hca_hdl IBTF channel Interface (TI) HCA Handle previously
> obtained
> 24 by calling ibt_open_hca(9F).
> 25
Yeah, it looks like a cut-n-paste mistake, since it mentioned the TI
stuff instead of CI. It should say the handle comes from the
ibc_hca_info_t returned via ibc_attach(). We will correct it.
-ted
--
Ted H. Kim
Sun Microsystems, Inc. ted.kim at sun.com
222 North Sepulveda Blvd., 10th Floor (310) 341-1116
El Segundo, CA 90245 (310) 341-1120 FAX
pixman [LSARC/2008/637 FastTrack timeout 10/22/2008]
I am sponsoring this fasttrack for Stuart Kreitman of the X team. The timer is set for next Wednesday, October 22. The case requests a patch release binding, though delivery is currently only planned for Nevada. -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: pixman 1.2. Name of Document Author/Supplier: Author: Stuart Kreitman 1.3 Date of This Document: 15 October, 2008 4. Technical Description "pixman is a library that provides low-level pixel manipulation features such as image compositing and trapezoid rasterization." It is consumed by Cairo and by the Xorg server 1.5. It has been delivered by JDS as a private interface for expediancy sake but was always intended to be delivered by the Xorg group. We're getting around to it now. The API is unmodified from the upstream X.Org community sources. This library is still under active development and refinement, and the community has not yet committed to keeping it compatible, so we are integrating with a stability level of Volatile at this time. The community has documented this versioning scheme to manage incompatible change: - Released development versions have an odd MINOR number - Released stable versions have an event MINOR number - Versions that break ABI must have a new MAJOR number - If you break the ABI, then at least this must be done: - increment MAJOR - In the first development release where you break ABI, find all instances of "pixman-n" and change them to pixman-(n+1) This needs to be done at least in configure.ac all Makefile.am's pixman-n.pc.in This ensures that binary incompatible versions can be installed in parallel. See http://www106.pair.com/rhp/parallel.html for more information We don't expect most user applications to consume this library - the expected consumers are the Xorg graphics drivers and the Cairo drawing libraries, so Volatile stability does not appear to pose a hardship to a significant number of consumers. Exported Interfaces: SUNWpixman Uncommitted /usr/include/pixman-1/pixman.h Volatile /usr/include/pixman-1/pixman-version.h Volatile /usr/lib/libpixman-1.so.0 Volatile /usr/lib/64/libpixman-1.so.0Volatile /usr/lib/pkgconfig/pixman-1.pc Volatile /usr/lib/64/pkgconfig/pixman-1.pc Volatile 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: X 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open
pixman [LSARC/2008/637 FastTrack timeout 10/22/2008]
Alan Coopersmith writes: > "pixman is a library that provides low-level pixel manipulation > features such as image compositing and trapezoid rasterization." Nature abhors an unrasterized trapezoid. ;-} > This ensures that binary incompatible versions can be installed > in parallel. See http://www106.pair.com/rhp/parallel.html for > more information That doesn't work as a precedent for Solaris (and probably not for any other OS with dynamic linking). The problem is that it runs right into the well-known single application address space problems. An application can easily end up with a melange of library versions colliding with each other through no fault of its own, and this scheme just enables that failure mode. I hope we're not really planning to apply it here. > We don't expect most user applications to consume this library - the > expected consumers are the Xorg graphics drivers and the Cairo drawing > libraries, so Volatile stability does not appear to pose a hardship > to a significant number of consumers. That seems like the good part. ;-} > /usr/lib/libpixman-1.so.0 Volatile Wouldn't we ordinarily call this something like "libpixman.so.1"? (It looks like this is an Ubuntuism, and other systems have it installed differently ... *sigh*.) -- 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
IBTF IO Memory [PSARC/2008/630 FastTrack timeout 10/17/2008]
Folks, We fixed up the man pages in the materials directory, so there are new versions of 1. ibt_alloc_io_mem.9f - remove the error about incompatible permissions 2. ibc_alloc_io_mem.9e - fix HCA handle description, plus the same fix as #1 here too 3. ibci.9 - add the see also ref (but only the ibc ref as this is describing CI things) I think this takes care of edits brought up so far. -ted -- Ted H. Kim Sun Microsystems, Inc. ted.kim at sun.com 222 North Sepulveda Blvd., 10th Floor (310) 341-1116 El Segundo, CA 90245 (310) 341-1120 FAX
IBTF IO Memory [PSARC/2008/630 FastTrack timeout 10/17/2008]
Ted H. Kim wrote: > Folks, > > We fixed up the man pages in the materials directory, > so there are new versions of > > 1. ibt_alloc_io_mem.9f - remove the error about incompatible > permissions > > 2. ibc_alloc_io_mem.9e - fix HCA handle description, plus > the same fix as #1 here too > > 3. ibci.9 - add the see also ref (but only the ibc ref > as this is describing CI things) Sorry I mean ibc_operation_t.9s for this last item. > > I think this takes care of edits brought up so far. > > -ted > > -- Ted H. Kim Sun Microsystems, Inc. ted.kim at sun.com 222 North Sepulveda Blvd., 10th Floor (310) 341-1116 El Segundo, CA 90245 (310) 341-1120 FAX
pixman [LSARC/2008/637 FastTrack timeout 10/22/2008]
pico-nit: - Released stable versions have an event MINOR number Should be - Released stable versions have an EVEN minor number Cheers Andrew. -- This message posted from opensolaris.org
pixman [LSARC/2008/637 FastTrack timeout 10/22/2008]
James Carlson wrote: > Alan Coopersmith writes: >> This ensures that binary incompatible versions can be installed >> in parallel. See http://www106.pair.com/rhp/parallel.html for >> more information > > That doesn't work as a precedent for Solaris (and probably not for any > other OS with dynamic linking). The problem is that it runs right > into the well-known single application address space problems. An > application can easily end up with a melange of library versions > colliding with each other through no fault of its own, and this scheme > just enables that failure mode. > > I hope we're not really planning to apply it here. Fully understood, and we already argued that with the maintainer when he implemented this scheme last year. His answer was: * Linking two incompatible versions of pixman into the same process can *never* work. It's retarded and irrelevant to the issue. I am not listening about obscure ELF and ld.so features. * Two incompatible versions of a library can be *installed* at the same time and linked to two different executables if the libraries have different names. This is useful and required so that separate projects can upgrade at separate times. [ http://lists.freedesktop.org/archives/xorg/2007-August/026876.html ] Certainly if there is ever a libpixman-2, we will have to be very careful about how it's integrated, but having Cairo on the client side link against libpixman-2 while Xorg links against libpixman-1 on the server side should work - it's just situations like Xorg using libpixman-1 while an Xorg driver links to libpixman-2 that we have to avoid. >> /usr/lib/libpixman-1.so.0Volatile > > Wouldn't we ordinarily call this something like "libpixman.so.1"? (It > looks like this is an Ubuntuism, and other systems have it installed > differently ... *sigh*.) Yes, but this is the name from upstream that will be used on all other OS'es, due to the above mentioned plan for allowing parallel versions to be installed. We've already got plenty of precedent for these in the GNOME libraries (since the referenced URL promoting this scheme comes from GNOME developer Havoc Pennington, who used it heavily in GNOME). -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
PSARC 2008/625 - Streamline ARC 20Q
> > Can I please ask for the 20Q document to be reposted in ASCII text > > so that it is easier for to quote and comment on it? [ taking psarc at sun.com off the mail as it is included in psarc-ext. This should stop the case log getting two copies of mail.] > 5. What are the security implications of this project? (Gary Winiger to > expand). > 9. Is systems administration needed for your project? If so, > > * How is the project administered, and what sort of review process has > this user > interface undergone? > * Is there a means of aggregating management and/or configuration with > other related > projects? > * Are there any external (to Solaris) management interfaces to consider, > or being > consumed? As I commented in ARC business today, here are my proposals for updates to the 20 Questions. The part noted as References or Appendix should be placed by the editor as appropriate. I'll try to update it soon with a short summary of what's in the specific policy/best practice and/or were it might be applicable. Are there other policies/best practices that should be added for example interface taxonomy and release binding? There are two cases referenced that I need to finish redacting. I should do that even if their references don't make the editorial cut ;-) The stuff enclosed in '[' ']' is intended for editor choice. Gary.. == 5. Security. Projects need to be aware of the overall security of the system and how their components affect it. Which parts of this project are critical to the security of the system to avoid such unintended consequences as unauthorized system entry, unauthorized access to or modification of data, elevation of privilege, denial of service, ...? A number of specific policies and practices address various aspects of the security of the system. They are found in [the references or appendix below]. Which of them are applicable to this project and how does this project address them? 9. System Administration. Projects that require or deliver administrative interfaces are often by their nature security components of the system and should likely address the Security question [with attention to RBAC and Audit]. Does this project require administration (i.e., configuration or management)? Where does its administration fit other related projects? Does it consume any external administrative/management interfaces? Does this project deliver its own administration along with the other components? Is this project an administration interface for other projects? If so, how is administration (configuration/management) addressed? == References or Appendix: Some specific security policy references are: --- Plugable Authentication Modules http://opensolaris.org/os/community/arc/policies/PAM/ Audit Policy http://opensolaris.org/os/community/arc/policies/audit-policy/ Service Management Facility (SMF) usage http://opensolaris.org/os/community/arc/policies/SMF-policy/ Install-Time Security http://opensolaris.org/os/community/arc/policies/ITS/ Network Install-Time Security http://opensolaris.org/os/community/arc/policies/NITS-policy/ Secure - by - Default http://opensolaris.org/os/community/arc/policies/secure-by-default/ --- Some general security best practice references are: --- When to use setuid -vs - RBAC roles and profiles http://opensolaris.org/os/community/arc/bestpractices/rbac-intro/ Building RBAC Rights Profiles http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ Adding RBAC Authorizations http://opensolaris.org/os/community/arc/bestpractices/rbac-auths/ Reusable Passwords in Command Line Arguments and Environment Variables http://opensolaris.org/os/community/arc/bestpractices/passwords-cli/ Storing Reusable Passwords on a FileSystem http://opensolaris.org/os/community/arc/bestpractices/passwords-files/ Administrative and Security Precedents and Policies http://opensolaris.org/os/community/arc/bestpractices/overview-admin-security/ Security Questions http://opensolaris.org/os/community/arc/bestpractices/security-questions/ --- Role Based Access Control and Privileges ARC cases are: --- RBAC: http://opensolaris.org/os/community/arc/caselog/1997/332 * PSARC/1997/332 Execution Profiles for Restricted Environments Need to redact. Privilege: http://opensolaris.org/os/community/arc/caselog/2002/188 * PSARC/2002/188 Least Privilege for Solaris Partially redacted. Need to complete.
libpciaccess & scanpci [PSARC/2008/638 FastTrack timeout 10/22/2008]
I am sponsoring this case for Stuart Kreitman & myself of the X team.
Edward Shu, who wrote the Solaris backend of the pciaccess code and
contributed it upstream, is also cc'ed.
The timeout is set for a week from today, Wednesday, October 15.
The requested release binding is patch/micro, though there are
no plans to backport to such a release at this time.
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
Template Version: @(#)sac_nextcase %I% %G% SMI
This information is Copyright 2008 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
libpciaccess & scanpci
1.2. Name of Document Author/Supplier:
Author: Stuart Kreitman & Alan Coopersmith
1.3 Date of This Document:
15 October, 2008
4. Technical Description
pciaccess is a set of methods for generic access to the PCI bus and devices
that X.Org has created to replace the internal code it previously used to
access PCI bus configuration data directly via drivers like /dev/xsvc.
The upcoming X.Org 1.5 case will depend on this project.
This project delivers the pciaccess API and scanpci CLI.
The API is unmodified from the upstream X.Org community sources.
This library is still under active development and refinement, and the
community has not yet committed to keeping it compatible, so we are
integrating with a stability level of Volatile at this time.
We don't expect most user applications to consume this library - the
expected consumers are the Xorg server & graphics drivers and the
included /usr/bin/scanpci CLI so Volatile stability does not appear to
pose a hardship to a significant number of consumers.
Since scanpci has been split out of the X server, and to make it easier to
find & use for users without /usr/X11/bin in their SUPATH for root, the
command is moved by this case to /usr/bin/scanpci. A symbolic link will
be left in the old location for binary compatibility.
Several options supported by the old scanpci implementation are no longer
present in the new scanpci, these are:
-1 Use PCI config type 1.
-2 Use PCI config type 2.
-f Used in conjunction with the above two options, this
forces the specified configuration type to be used
for config space access.
-O Use the OS's PCI config space access mechanism to
access the PCI config space (when available).
-V nSet the verbosity level to n for the internal PCI
scanner. This is primarily for debugging use.
scanpci continues to require extra privileges to run. The exec_attr
RBAC entry to grant these privileges to users with the
"Desktop Configuration" role will be updated to add the new scanpci path.
Unlike the Xorg code this replaces, this code does not have a builtin
database to map PCI vendor and device ids to human readable names, but
gets those names from the pci.ids file at runtime. (This is the same
community data source as the previous scanpci, just read from a text
file at runtime instead of converting the text file into compiled tables
at build time.)
Imported Interfaces:
/usr/X11/bin/scanpci & previous options ExternalPSARC 2004/187
/usr/share/hwdata/pci.ids VolatilePSARC 2005/399
/devices/pci at 0,0:reg Unknown - ARC case not found
/dev/xsvc Contract PrivatePSARC 2000/415
libdevinfo EvolvingPSARC 1997/127
PCITOOL_DEVICE_GET_REG Consolidation Private PSARC 2005/232
PCITOOL_DEVICE_SET_REG Consolidation Private PSARC 2005/232
Exported Interfaces:
SUNWpciaccess Uncommitted
/usr/bin/scanpciVolatile
/usr/include/pciaccess.hVolatile
/usr/lib/libpciaccess.so.0 Volatile
/usr/lib/{sparcv9,amd64}/libpciaccess.so.0 Volatile
pciaccess.pc (for pkg-config) Volatile
scanpci output format Not An Interface
/usr/X11/bin/scanpciObsolete
scanpci options listed aboveRemoved
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
X
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
libpciaccess & scanpci [PSARC/2008/638 FastTrack timeout 10/22/2008]
Alan Coopersmith wrote: > The timeout is set for a week from today, Wednesday, October 15. Today is October 15, so the timer expires next Wednesday, October 22, as sac_nextcase correctly put in the header. (Why do you never see these typos before hitting send, but spot them the moment it appears in your inbox?) -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
libpciaccess & scanpci [PSARC/2008/638 FastTrack timeout 10/22/2008]
Edward Shu wrote: > >> /dev/xsvcContract PrivatePSARC 2000/415 >> >> > If we have a more flexible mapping interfaces to map in any memory on > board, we can remove this > dependency finally. > I think the preferred direction is in fact less flexible mapping interfaces, because unfettered access is contrary to a more secure operating system. Stuart
