SMF Early Manifest Import [PSARC/2010/013 FastTrack timeout 01/20/2010]
Hi Tom, Tom Whitten p??e v st 13. 01. 2010 v 15:18 -0700: > Scott Rotondo writes: > > >Manifest files will be imported from a new location that is available > > >at the time Early Manifest Import is executed. Root (/) will be > > >available, and as part of that /lib will be available. Therefore > > >manifest files located under /lib/svc/manifest and > > > /lib/svc/manifest/site > > >will be imported during the execution of Early Manifest Import. > > >As part of this project, the ON manifest files that are currently > > >delivered under /var/svc/manifest will be moved to /lib/svc/manifest. > > >After this change, the recommended best practice is manifest files > > >be delivered under /lib/svc/manifest subtrees to take advantage of > > >Early Manifest Import. > > > > This (logical) recommendation leads to another question: Is there a > > particular situation where one should prefer/require late import of a > > manifest? > > We wanted to continue to support manifest in /var, so that non-ON > consolidations and third party developers would not need to abruptly change > their packages. > > > > > If not, would it make sense to eliminate Late Manifest Import and leave > > /var/svc/manifest as a symlink to /lib/svc/manifest? > > In the early phases of the EMI project, we actually considered making > /var/svc/manifest a symlink. The feedback that we received, however, > indicated that it would no play well with SVR4 packaging. See > http://mail.opensolaris.org/pipermail/smf-discuss/2008-April/004111.html. > We also received indications that the symlink would not play well with > pkg(5), but I don't have any emails that I can refer you to for that. > But that is problem of packaging system (both of them), which should be fixed to deal with such situations (is it the first time when we are doing such change on filesystem hierarchy?). Why should we introduce such misleading "duplication" of places? Any benefit to have 2 places? Best regards, Milan
GLUT [LSARC/2010/016 FastTrack timeout 01/21/2010]
I am sponsoring this fasttrack for Stefan Teleman, and have set the timeout for a week from now, next Thursday, January 21. The case materials directory includes an additional document, glut-appendix-1.txt with a list of the functions in the GLUT API. -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2010 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: GLUT 1.2. Name of Document Author/Supplier: Author: Calin Teleman 1.3 Date of This Document: 14 January, 2010 4. Technical Description Introducing GLUT [ The OpenGL Utility Toolkit ] with X11 in Solaris Stefan Teleman 7 January 2010 1. Summary and Motivation GLUT [ The OpenGL Utility Toolkit ] [0] is a collection of functions providing a standardized access to a windowing system and to various input devices, in a platform-independent manner, and within an OpenGL [1] Context. The main purpose of GLUT is the avoidance of clobbering the OpenGL namespace with device, platform and operating-system specific functions. This platform independence comes at the expense of full device interaction features availability, and some loss of programming flexibility. From the FreeGLUT page: GLUT (and hence freeglut) allows the user to create and manage windows containing OpenGL contexts on a wide range of platforms and also read the mouse, keyboard and joystick functions. GLUT also provides general-purpose APIs simplifying some standard OpenGL programming idioms. Absent these GLUT APIs, these idioms would have had to be duplicated by the application programmer, for every OpenGL application. GLUT was originally developed and maintained by Mark Kilgard at SGI, under a very restrictive license. The last release from SGI was GLUT 3.7, in August 1998. Due to the licensing restrictions imposed by the canonical GLUT 3.7 license, and to the fact that it has not had a canonical upgrade release since August 1998, the SGI GLUT releases are not being considered for integration, and will not be discussed further. The GLUT API had been frozen at Version 3 since August 1998, and the GLUT releases have been frozen at Version 3.7. According to the OpenGL GLUT information page: [0] The current [ GLUT ] version is 3.7. Additional releases of the library are not anticipated. The current version of the GLUT API is 3. The current source code distribution is GLUT 3.7. The FreeGLUT Project [2] is a compatible replacement for the GLUT API V3 [ SGI GLUT 3.7 ], and is released under the MIT/X Consortium License. The FreeGLUT Project has extended and upgraded the SGI GLUT API version to Version 4. [4] The GLUT API Version 4 is a fully backwards compatible superset of Version 3 of the SGI GLUT API. The latest release from the FreeGLUT project is Version 2.6.0, and implements the GLUT API Version 4. For the purposes of this document, the term GLUT and FreeGLUT are used interchangeably, and refer to the canonical releases from the FreeGLUT project. This Case seeks Micro/Patch binding. 2. Programmatic Facilities The SGI [ Version 3 ] GLUT API and the FreeGLUT [ Version 4 ] API are documented in detail at [3] and [4]. A complete list of all the public interfaces exported by GLUT is provided in Appendix 1 in the Case Materials. Version 4 of the GLUT API provides a Standard API, available via the freeglut_std.h header file, and an Extensions API, available via the freeglut_ext.h header file. Access to the Standard GLUT API is provided by the glut.h header file. Access to the Standard And Extensions API is provided by the freeglut.h header file. The current GLUT API depends on the X11 Display structure. It has not yet been ported to XCB. [5] [6] 3. Interface Considerations GLUT imports interfaces from OpenGL [ libGL.so.1 and libGLU.so.1 ]. This is an explicit dependency: internal GLUT header files explicitly include and . GLUT does not specify a lower bound OpenGL API Version. FreeGLUT compiles cleanly with OpenGL Version 1.5. Additionally, GLUT imports interfaces from the following X libraries: - libX11.so.4 - libXext.so.0 - libXi.so.5 - libXxf86vm.so.1 GLUT exports C and [ identical ] C++ interfaces. The GLUT API Version 4 maintains backward compatibility with Version 3
OpenSolaris ARC Agenda - January 19 & 20
http://hub.opensolaris.org/bin/edit/Community+Group+arc/ARCAgenda/ = OpenSolaris ARC Agenda = TELECONFERENCE NUMBERS: (866)545-5223 (Within US) (215)446-3661 (International) ACCESS CODE 939-55-86 Times are US/Pacific Timezone ARC meetings are recorded. 01/19/2010 10 min Open ARC Business 10 min Closed ARC Business DELETE CLOSED CASE Fast-tracks: Case (Timeout) Exposure Title 2009/603 (01/12/10) open Nagios 2009/658 (12/23/09) open Ganglia 2010/016 (01/21/10) open GLUT 01/20/2010 10 minutes Open ARC Business (use open dial in above) 45 minutes Pluggable TCP Congestion Control (2009/629) Submitter: artem.kachitchkin at sun.com Exposure: open 10 minutes Closed ARC Business (use closed dial in above) DELETE CLOSED CASE Fast-tracks: Case (Timeout) Exposure Title 2009/642 (01/19/10) open audit_control(4) EOL and removal 2009/673 (12/16/09) open CIFS Service Kerberos user authentication for AD users 2009/682 (01/13/10) open Update Samba to release 3.4 2009/687 (01/05/10) open Add function pool_is_readonly_property to libpool 2009/689 (01/05/09) open Audio DDI Simplifications 2010/004 (01/14/10) open Logical Domains Information API and ldminfo 2010/006 (01/13/10) open EOF of iSCSI Target Daemon 2010/009 (01/14/10) open Modified ZFS passthrough-x ACL inheritance 2010/010 (01/15/10) open Upgrade GPL Ghostscript to version 8.64 2010/013 (01/20/10) open SMF Early Manifest Import
Audio DDI Simplifications [PSARC/2009/689 FastTrack timeout 01/05/2009]
+1 -Seb
Logical Domains Information API and ldminfo [PSARC/2010/004 FastTrack timeout 01/14/2010]
On 01/13/10 15:55, Rick Matthews wrote: > There was no meeting scheduled for Jan. 13. > > I believe a question was asked (and if not, I'll ask it) as to why an > LDOMs specific > virtualization query? Would there be a query that could give the caller > "generic" virtualization > information (working for both Zen and LDOMs)? Was this considered? No, we didn't really consider Xen support. I'm engaging the Xen group right now to see if there's easily achievable common ground. > Could a generic call identify the virtualization technology, and > then, if needed, technology specific queries could be made? Yes, if it's not easy to converge with Xen, we can supply that. It's probably going to take me a couple of days to resolve these issues. Mike > -- > Rick > > On 01/04/10 17:00, Huay-Yong Wang wrote: >> I am sponsoring this fasttrack for Michael Christensen. >> The project team is requesting a patch/micro release binding. >> The 3 manpages (ldminfo.1m, libldom.3lib & >> ldoms_capabilities.3ldoms) and the libldoms.h include >> file are placed in the case directory. >> >> The timer is set to expire on 1/14/10. >> >> --- >> >> 1. Introduction >> >> 1.1 Project/Component Working Name >> >> Logical Domains Information API and ldminfo program >> >> 1.2 Name of Document Author/Supplier >> >> Michael Christensen >> >> 1.3 Date of This Document >> >> 18-DEC-2009 >> >> 1.4 Name of Major Document Customer(s)/Consumer(s) >> >> 1.4.1 The PAC or CPT you expect to review your project >> >> 1.4.2 The ARC(s) you expect to review your project >> >> PSARC >> >> 1.4.3 The Director/VP who is sponsoring this project >> >> jerriann.meyer at sun.com >> >> 1.4.4 The Name of Your Business Unit >> >> Solaris Core OS >> >> 1.5 Email Aliases >> >> 1.5.1 Responsible Manager:jay.jayachandran at sun.com >> >> 1.5.2 Responsible Engineer:michael.christensen at sun.com >> >> 1.5.3 Marketing Manager:duncan.hardie at sun.com >> >> 1.5.4 Interest List:ldoms-internal at sun.com >> >> 2. Project Summary >> >> 2.1 Project Description >> >> This project will implement Logical Domains Information API >> and ldminfo program on Solaris. The API and ldminfo >> program will provide information about the currently running >> domain. Among the items that may be provided are: >> >> - Domain type (control, guest, I/O, service, root) >> - LDom Manager's LDom name for this domain (Domain name) >> - Domain Universally Unique ID (UUID) >> - Domain's control domain network nodename >> - Chassis Serial Number the domain is running on. >> >> None of the above items are currently easily obtainable from >> within a guest domain. As an example, many customers have >> expressed a desire to run LDom manager scripts on the >> control domain initiated from a guest domain. However, there >> is no easy way to either identify the network nodename of the >> control domain or to identify the LDom Manager's name for the >> current domain, which would be required for LDom Manager >> commands. Further, many customers have requested a means of >> uniquely identifying each domain and also identifying the >> hardware platform that the domain is running on for >> accounting or resourcing. >> >> On the Solaris operating system, the Logical Domains Information >> API will be implemented as a library (libldoms) using >> information from the Guest Domain's Machine Description provided >> by FWARC 2005/115 (sun4v machine description), the sun4v MD >> uuid property from FWARC 2009/680 (Domain UUID property), the >> libds library provided by PSARC 2008/568 (Logical Domain's Domain >> Services) and using domain services provided by the logical >> domain agent daemon provided by PSARC 2009/459 (Logical Domains >> Agents on Solaris) and FWARC 2009/426 (Logical Domains Agents). >> The ldminfo program will utilize the libldoms library to display >> the various items of information provided. >> >> 2.2 Risks and Assumptions >> >> None. >> >> 3. Business Summary >> >> 3.1 Problem Area >> >> In an LDoms system, a user program or user has no easy way >> to identify what type of domain the program is being run >> on (e.g. control domain, guest domain, I/O domain, service >> domain). Also a guest domain has no easy way to identify the >> network nodename of its control domain, what name the LDoms >> Manager running on the control domain uses to identify this >> domain, what is the domain's Universally Unique Identifier that >> The LDoms Manager uses to identify this domain or what the >> Chassis Serial Number of the platform it is currently running >> on. >> >> 3.2 Market/Requestor >> >> See FWARC 2005/633. >> >> 3.3 Business Justification >> >> See FW
SMF Early Manifest Import [PSARC/2010/013 FastTrack timeout 01/20/2010]
On 01/13/10 23:12, Milan Jurik wrote: >> In the early phases of the EMI project, we actually considered making >> /var/svc/manifest a symlink. The feedback that we received, however, >> indicated that it would no play well with SVR4 packaging. See >> http://mail.opensolaris.org/pipermail/smf-discuss/2008-April/004111.html. >> We also received indications that the symlink would not play well with >> pkg(5), but I don't have any emails that I can refer you to for that. >> > > But that is problem of packaging system (both of them), which should be > fixed to deal with such situations (is it the first time when we are > doing such change on filesystem hierarchy?). Why should we introduce > such misleading "duplication" of places? Any benefit to have 2 places? > > Best regards, > > Milan > > > > ___ > opensolaris-arc mailing list > opensolaris-arc at opensolaris.org The issue is that if some package treat /var/svc/manifest as a symlink, and others as a directory, we'll end up w/ problems. The packaging system cannot deal with discordant views of the file system hierarchy in a rational fashion. We can always fix the packages in the wos, but third parties may deliver SMF manifests to a directory named /var/svc/manifest for years. It's best that we leave it there to prevent problems. - Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird."
SMF Early Manifest Import [PSARC/2010/013 FastTrack timeout 01/20/2010]
On 01/14/10 01:43 PM, Bart Smaalders wrote: > On 01/13/10 23:12, Milan Jurik wrote: > >>> In the early phases of the EMI project, we actually considered making >>> /var/svc/manifest a symlink. The feedback that we received, however, >>> indicated that it would no play well with SVR4 packaging. See >>> http://mail.opensolaris.org/pipermail/smf-discuss/2008-April/004111.html. >>> >>> We also received indications that the symlink would not play well with >>> pkg(5), but I don't have any emails that I can refer you to for that. >>> >> >> But that is problem of packaging system (both of them), which should be >> fixed to deal with such situations (is it the first time when we are >> doing such change on filesystem hierarchy?). Why should we introduce >> such misleading "duplication" of places? Any benefit to have 2 places? > The issue is that if some package treat /var/svc/manifest as a symlink, > and others as a directory, we'll end up w/ problems. The packaging > system cannot deal with discordant views of the file system hierarchy > in a rational fashion. We can always fix the packages in the wos, but > third parties may deliver SMF manifests to a directory named > /var/svc/manifest for years. It's best that we leave it there to prevent > problems. Right. It makes no sense to place the burden on the project team to fix all Sun-delivered, third-party, and home-grown packaging or install software systems to ensure that they cope with an ARC-Committed directory changing to a symlink. The fact that we have two examples which are not tolerant to it today was taken by the project team as a sign that they should pursue another course of action, and they did. The high-level point here is that we're talking about a filesystem location which is Committed as a delivery directory for ISVs and customers, so it must be handled with care in order to maintain compatibility. liane
PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010]
I am sponsoring the following fast-track on behalf of Jan Setje-Eilers with a time-out of 01/22/2010. The project desires minor binding. -- Bitmapped ConsolePSARC/2009/415 1) Summary The Bitmapped Console brings Support for higher resolutions and color depth than the current VGA 640x480 16-color console on x86 systems. The initial delivery will support x86 systems using traditional BIOS and VESA option ROMs. EFI systems, once supported will leverage this work to enable their frame buffer consoles. 2) Technical Details The following applies when a graphics card / frame buffer is being used as a physical or virtual console. This project does not change the behavior of serial consoles. 2.0) Overview The loader (GRUB) automatically chooses an appropriate video mode by intersecting available VESA modes with EDID reported display capabilities and activates it. Any failure to obtain EDID or make VESA calls will leave the system in VGA text mode which the OS will use as it did previously. Then it loads the OS as before and hands a description of the mode to the OS via the vbe members of the multiboot info structure. The early boot_console code which is used pre-consconfig for console messages as well as early kmdb interaction uses that description to map the described frame buffer region and uses it as a bitmapped console device. At consconfig gfx_private (which this project makes vgatext a consumer of) takes over this role and the coherent console (tem) is used to display the console on this frame buffer. Side note: vgatext does not gain any specific vesa support, so it is not being re-named. It simply passes down tem IOCTLs and gfx_private will act appropriately. During a typical non-interactive boot the current "happy face" soothing image gains higher resolution and color depth typically 16-bit, often at a native panel resolution, a significant improvement over 640x480 at 4-bit. Any of the following events will stop the animation, clear the screen and display the text that would otherwise have been on the console at that point: Entering kmdb by any means: mdb -K, panic, F1-a Booting -kd skips graphics entirely as immediate interaction is required. sulogin running on console Any key-press post kbtrans attach (prior to which only kmdb can be interacted with). The console login prompt is displayed and X is not expected to start. This is determined by: svc:/system/console-login:default being on-line while any service svc:/application/graphical-login is disabled or in maintenance. If a graphical-login is enabled a couple seconds is allowed for X to start and take over the console frame buffer, then another reset to text mode is attempted. This simply fails if X owns the console device at that point, but catches configurations that run graphical-login services without running X on console such as sunray servers. 2.1) Mode setting by GRUB The GRUB splashimage command recognizes png files and will select an appropriate mode based on the cards advertised VESA modes and the display capabilities derived from the displays EDID. While the splashimage command can precede the rest of the script comprising the menu entry, the actual mode setting is deferred until the rest of the other commands have succeeded (which means that at least a bootable kernel has been loaded). 2.2) Graphical boot During graphical boot /boot/solaris/boot-images/boot.png is displayed as the background. To indicate progress /boot/solaris/boot-images/stepN.png where N=0 to 14 are used to display an alpha blended animation. Fewer than 15 images may be provided. This animation is displayed until either a key is pressed to switch to text, or X takes over the console. If gdm is not enabled, console login triggers a switch to text. Lastly boot/solaris/images/shutdown.png is displayed during shutdown. This can be disabled by setting load_shutdown_image on the system/console-status service to false. PNG was chosen based both on being a technically appropriate format as well as it's attempt to avoid the licensing quagmire that has plagued other formats. The png parsing code is based on pnglite v. 0.1.17 which is covered by OSR 12682. 2.3) Console text mode Console text mode will continue to default to 80 columns by 24 rows, but becomes configurable via the screen-#columns and screen-#rows properties (as seen in OBP). This uses the existing algorithms in tem that will pick an appropriately sized font and make a best effort at achieving the desired rows and columns. For e
LSARC/2010/018 - Mechanism for facilitating the installation of OpenOffice.org on, Solaris
All, I am sponsoring this case for Laszlo (Laca) Peter of the Desktop group. The timer is set for Thursday, January 21, 2010. The case directory contains the attached proposal. The EOF Bundled StarOffice 8 case (LSARC/2010/017) removes StarOffice from Solaris 10 Update 9. This case proposes to integrate a mechanism to facilitate the installation of Open Office into a Patch release of Solaris. This will be accomplished by the use of a .desktop file, local URL and a shell script. These interfaces are declared Project Private. Thanks, John -- next part -- An embedded and charset-unspecified text was scrubbed... Name: proposal.txt URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20100114/d8bd014d/attachment.txt>
PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010]
Aaron Zang wrote: >> 2.4) Resetting frame buffer state on exit from X >> >>On exit X will generally attempt to restore the mode the card was >>in before it started. While some native drivers do restore enough >>state to reset a VESA mode properly, a number do not. >> >>Since it is impractical to test and fix every native driver on all >>cards, a method for explicitly setting the VESA mode at OS run-time >>is used. Setting the mode requires execution of a call into the >>VESA BIOS supplied by the card. This is achieved via vbiosd, a >>daemon that provides userland x86 realmode emulation. This daemon >>is a derivative work based on uvesafb::v86d, covered by OSR 12387. >> >>While the mode is set by vbiosd in userland, the state continues to >>be tracked by the KD_TEXT/KD_GRAPHICS states in the gfx_private >>lower-layer of the kernel driver. Mode changes happen in >>gfx_private and invoke vbiosd via a door. >> >>If X does not exit cleanly, the native driver can leave the card >>in an unknown state. This project does not change that behavior. >> >>vbiosd is managed by svc:/system/vbios. While it is only required >>when X is running, an effort must be made to keep the console in >>a sane state when X is started by something other than smf, such as >>say running Xorg manually, so the vbios service is always started. >> > > Hi Jerry, > Good to see this going. I have something unclear about this section. > The graphic card might not always be in VESA (KD_TEXT) mode before an X > server starts. > This is true when an second X server is started while the first X server > is in control of the graphic card. It is now supported with virtual console > and new gdm. Xorg's saving/restoring graphic context while starting/exiting > or switching to/from via user land DDX driver works fine now. > I am not sure that there won't be any problems if we make such assumption > and restore the graphic card to VESA mode every time the X server exits. In this case exiting really means that the X server explicitly sets KD_TEXT as part of releasing the device and turning control back over to the text console. This shouldn't happen unless the intent is to at least temporarily hand control of the frame buffer back to the text console, in which case there should not be a problem. If the X server ever sets KD_TEXT in a scenario where the graphics card is used in a native mode by another X server, I would expect problems even with just the VGA support. -jan
