BSD List Interfaces [PSARC/2010/028 FastTrack timeout 02/01/2010]
On 25/01/2010 8:49 PM, James Carlson wrote: Darren Reed wrote: * single linked list * double linked list * tail queue singly linked tail queue * simple queue * circular queue Looks good. Are these intended as both kernel and user or just kernel only (as sys/ might imply)? The interfaces as presented can be used for both user and kernel. Perhaps not strictly architectural in nature, but are any mdb walkers and/or dcmds provided to help out when using these, as we have for the native list_t mechanism? If not, you may want to consider investigating those. Current there are no mdb walkers or dcmds. Seems like a worthy RFE or two. Darren
BSD List Interfaces [PSARC/2010/028 FastTrack timeout 02/01/2010]
I can't see why not - afterall, the contents of the page will be largely the same. Darren On 25/01/2010 7:57 PM, Garrett D'Amore wrote: Looks reasonable. Will you also be providing a section 9f man page for kernel/driver developers? - Garrett Darren Reed wrote: Introduction As part of an earlier project, the macros created for 4.4BSD were added to the system as part of the project's implementation. This case seeks to document those interfaces and to make them available for wider use on Solaris. The interfaces included as a part of this case provide an easy to use, type safe, implementation of linked lists and queues. In addition to providing the aforementioned interfaces to internal developers, the delivery of the interfaces in this case has increased the compatibility of Open/Solaris with open source applications from other platforms. A man page can be found within the case directory. The man page and implementation both originate from NetBSD. This case seeks patch binding. Details === The current implementation of the BSD macros for supporting both list and queue data structures is found within /usr/include/sys/queue.h. The filename and location have been mirrored on Solaris. This file introduces the following types of data structures: * single linked list * double linked list * tail queue singly linked tail queue * simple queue * circular queue Single Linked List -- A singly-linked list is headed by a single forward pointer. The elements are singly linked for minimum space and pointer manipulation overhead at the expense of O(n) removal for arbitrary elements. New elements can be added to the list after an existing element or at the head of the list. Elements being removed from the head of the list should use the explicit macro for this purpose for optimum efficiency. A singly-linked list may only be traversed in the forward direction. Singly-linked lists are ideal for applications with large datasets and few or no removals or for implementing a LIFO queue. Double Linked List -- A list is headed by a single forward pointer (or an array of forward pointers for a hash table header). The elements are doubly linked so that an arbitrary element can be removed without a need to traverse the list. New elements can be added to the list before or after an existing element or at the head of the list. A list may only be traversed in the forward direction. Simple Queue A simple queue is headed by a pair of pointers, one the head of the list and the other to the tail of the list. The elements are singly linked to save space, so elements can only be removed from the head of the list. New elements can be added to the list after an existing element, at the head of the list, or at the end of the list. A simple queue may only be traversed in the forward direction. Tail queue -- A tail queue is headed by a pair of pointers, one to the head of the list and the other to the tail of the list. The elements are doubly linked so that an arbitrary element can be removed without a need to traverse the list. New elements can be added to the list before or after an existing element, at the head of the list, or at the end of the list. A tail queue may be traversed in either direction. Circle Queue A circle queue is headed by a pair of pointers, one to the head of the list and the other to the tail of the list. The elements are doubly linked so that an arbitrary element can be removed without a need to traverse the list. New elements can be added to the list before or after an existing element, at the head of the list, or at the end of the list. A circle queue may be traversed in either direction, but has a more complex end of list detection. Interfaces == sys/queue.h Committed LIST_HEAD Committed LIST_ENTRY Committed LIST_INIT Committed LIST_INSERT_AFTER Committed LIST_INSERT_BEFORE Committed LIST_INSERT_HEAD Committed LIST_REMOVECommitted LIST_FOREACH Committed LIST_EMPTY Committed LIST_FIRST Committed LIST_NEXT Committed SLIST_HEAD Committed SLIST_ENTRYCommitted SLIST_INIT Committed SLIST_INSERT_AFTER Committed SLIST_INSERT_HEAD Committed SLIST_REMOVE_HEAD Committed SLIST_REMOVE Committed SLIST_FOREACH Committed SLIST_EMPTYCommitted SLIST_FIRSTCommitted SLIST_NEXT Committed STAILQ_HEADCommitted STAILQ_ENTRY Committed STAILQ_INITCommitted STAILQ_INSERT_HEAD Committed STAILQ_INSERT_TAIL Committed STAILQ_INSERT_AFTERCommitted
EOF evolution-jescs [LSARC/2010/027 FastTrack timeout /02/02/2010]
Milan, I just asked our desktop RE (Dave Lin) and he told me currently it is still in the SVR4/IPS transition period, and it is no harm to deliver the ph files. If it is not needed when we do the real remove in B140, we can just ignore that step. Thanks, Harry On Mon, 2010-01-25 at 16:06 +0100, Milan Jurik wrote: Hi, Harry Lu p??e v po 25. 01. 2010 v 22:48 +0800: John, The package history is usually handled by our desktop REs. So yes, I think they will create one for this EOF. Isn't package history only for SVR4 packaging? And this has only minor binding. Best regards, Milan Thanks, Harry On 2010/1/25 22:06, John Fischer wrote: Jeff, Will there be package history files for folks upgrading from one build to another? Otherwise, +1. John On 01/24/10 07:33 PM, Qing-Ming Jeff Cai wrote: 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: EOF evolution-jescs 1.2. Name of Document Author/Supplier: Author: Jedy Wang 1.3 Date of This Document: 24 January, 2010 4. Technical Description 1. Introduction 1.1. Project/Component Working Name: EOF of evolution-jescs 1.2. Name of Document Author/Supplier: Author: Jedy Wang 1.3 Date of This Document: 15 January, 2010 4. Technical Description 1.0 Description: EOF of evolution-jescs 1.1 Project Detail This project proposes to remove evolution-jescs in Solaris. The evolution-jescs module is the Sun Calendar backend for the Evolution mail client. It provides Evolution with the ability to connect with the Sun Calender server. Since 2.29.x, the Evolution community has begun to remove the Bonobo dependency and has changed the architecture. Since evolution-jescs has a strong dependency on Bonobo and the old architecture, it won't work moving forward. For these reasons, it will be deprecated. The following reasons explain why the removal of evolution-jescs will have little impact to the end-user. 1) The Lightning Thunderbird plugin (LSARC/2007/043) supports the Sun Calendar server already and Thunderbird is the default mailer for Solaris. 2) The new Sun Calendar server (v7) released in 2009 uses a new protocol called CalDAV and the support for the old protocol will be limited to and tailored for the Convergence client and Outlook connector support. 3) Both Lightning and Evolution support CalDAV, so both of them can support the new calendar server. 4) After the removal of evolution-jescs, users who want to continue to use the old Sun Calendar Server need only to setup a new Sun Calendar server account in thundbird to migrate from Evolution to Thunderbird which is fairly simple. 1.2 Packaging and Release Binding SUNWevolution-jescs will be removed in a minor release binding. 1.3 Documentation N/A 1.4 Dependency The removal of this project is dependent upon the integration of Lightning (LSARC/2007/043) which has been already integrated into Solaris. 2.0 Interface Tables 2.1 Removed Interfaces Interface StabilityComments - --- - /usr/lib/evolution/*/evolution-jescs Obsolete GUI Uncommitted /usr/lib/evolution-data-server-1.2/camel-providers/libcamelsunone.so Obsolete Library Project Private SUNWevolution-jescsObsolete Package Uncommitted 2.2 Imported Interfaces InterfaceStability Comments --- -- N/A 3.0 References LSARC 2007/043 Lightning 0.3 LSARC 2003/298 Sun Evolution 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 ___ opensolaris-arc mailing list opensolaris-arc at opensolaris.org ___ opensolaris-arc mailing list
Sun GlassFish Web Stack 1.6 [LSARC/2010/026 FastTrack timeout 01/29/2010]
Jyri Virkki wrote: Jeff Trawick wrote: Attached is a draft extraction/description of the parts of this ARC which represent 1.5 to 1.6 changes. (The team hasn't reviewed in detail). Does this information need to be integrated into the ARC? Don't duplicate info or split it in unnatural ways. However, it might be useful to mark sections which are new to 1.6 with a small tag, maybe [1.6] or some such. will-do (I'll circulate an update within the team before reposting to this thread) Section 2.1 What's incompatible between the MySQL 5.0 and 5.1 releases? [...] Do this information need to be integrated into the ARC? Unless this case is introducing some change here above and beyond what was already documented in the MySQL 5.1 ugprade case LSARC/2009/062, then no, those changes are not this case. I thought the MySQL changes being ported to S10/RH for Web Stack 1.6 are identical to what was covered earlier in 2009/062, right? correct; LSARC/2009/062 covers the differences
[osol-help] problem with zfs command
No, I don't think that you are an idiot. You tried some setup and you tried at least Google and this is more then most of the people do when there is something wrong. My point was that Solaris/OpenSolaris and BSDs have best man pages and documentation available so it's really good idea to use them as much as possible because most of the posts on the Internet/blogs/forums are simply wrong. I know that this is typical habit on Linux because its man pages are horrible. Info from man page and your error leads to conclusion that single quotes are needed. If problem is same with or without them then maybe you found a bug. yah that is exactly what is going on. I read the manual and when i tried that it didn't work. I was pretty sure it was a bug but i didn't know if there was another way to solve this. I've recently moved from FreeBSD to OpenSolaris and while i agree that the manuals are good, OpenSolaris doesn't have anything like the FreeBSD handbook that i can find. There is a lot of GREAT info out there, it's just not all in one place. I try to find out as much as possible before postingturns out this is a bug for sure. http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6912791 -- This message posted from opensolaris.org
[osol-help] problem with zfs command
On 01/26/10 10:58 AM, Thomas Burgess wrote: No, I don't think that you are an idiot. You tried some setup and you tried at least Google and this is more then most of the people do when there is something wrong. My point was that Solaris/OpenSolaris and BSDs have best man pages and documentation available so it's really good idea to use them as much as possible because most of the posts on the Internet/blogs/forums are simply wrong. I know that this is typical habit on Linux because its man pages are horrible. Info from man page and your error leads to conclusion that single quotes are needed. If problem is same with or without them then maybe you found a bug. yah that is exactly what is going on. I read the manual and when i tried that it didn't work. I was pretty sure it was a bug but i didn't know if there was another way to solve this. I've recently moved from FreeBSD to OpenSolaris and while i agree that the manuals are good, OpenSolaris doesn't have anything like the FreeBSD handbook that i can find. There is a lot of GREAT info out there, it's just not all in one place. I try to find out as much as possible before postingturns out this is a bug for sure. http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6912791 The fix should be delivered in build 132. -- Shawn Walker
Improved ACL interoperability [PSARC/2010/029 FastTrack timeout 02/02/2010]
I am sponsoring the following fasttrack for Mark Shellenbaum. This case modifies the behavior of ZFS acls to improve the interoperability story when ZFS file systems are shared using NFS and CIFS. The case seeks micro/patch binding. Timeout is 2/2/2010. 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: Improved ACL interoperability 1.2. Name of Document Author/Supplier: Author: Mark Shellenbaum 1.3 Date of This Document: 26 January, 2010 4. Technical Description Executive Summary: This case changes the default behavior of ACLs for CIFS and NFS so that it is easier to understand with *fewer* configuration knobs. The new default behavior remains POSIX compliant and is more in line with the expectation of CIFS users, local ZFS users, and NFS users. This case does not introduce any changes that would cause files to have more permissable access than the previous behavior. Problems: A number of issues have turned up with trying to do cross protocol (NFS/CIFS) sharing of ZFS file systems. - Deny ACES in standard trivial ACLs cause issues for the Windows ACL GUI, which then results in ACLs being resorted and the access to the file changed. - ZFS computes a mode based on the presence of the owner@, group@ and everyone@ ACES. The Solaris CIFS server usually creates files that only have a user and group ACE and no owner@, group@ or everyone@ entries. This is because Windows has no knowledge of owner@ and group@ ACEs. Those are NFSv4 extensions. This results in files being created with a mode of zero and that confuses customers. - chmod(2) behavior under ZFS has caused a lot of confusion among customers. ZFS tries to preserve ACLs during chmod(2) and this often causes the ACL to change in a very non-intuitive way and results in a constant stream of questions on multiple mailing lists. The chmod(2) behavior also gives the Windows ACL GUI issues due to the insertion of deny ACEs. Solutions: - ZFS can create trivial ACLs that don't require deny ACEs for all but unusual permissions. For example a mode of 0644, 0755, 0664 do not need deny ACEs, but modes, such as 0705, 0060 and so on, will require deny ACEs. Examples of the new layout are described later in this document. - Inheritance changes. ZFS splits ACEs into multiple ACES during inheritance to try to preserve the original permission unmodified. It does this by creating a inherit_only ACE. This has been a point of confusion with customers who don't understand where the inherit_only ACE came from. The solution is to stop doing the splitting operation and just modify the permissions as necessary to enforce the mode of file create. - The semantics of the aclinherit property will change to include trimming down permissions when the property is set to restricted. The effect of this will be the same as what the old aclmode property would do when set to groupmask, except that it won't be doing the ACE splitting described above. - ZFS appears to be the only file system supporting NFSv4 ACLs that attempts to preserve ACLs during chmod(2) operations. Unfortunately, this requires the ACL to be modified in ways that are confusing to customers and the time has come to stop the confusion and to just discard the ACL during chmod(2) operations. This implies that the ZFS aclmode property will no longer be needed and will be removed from ZFS. - New mode calculation rules. If an ACL has a user ACE that is also the file owner, then those permissions will be included in the computation of the mode. The same is also true if a group ACE is the group owner of the file. New ACE Layout Examples File with a mode of 0644: -rw-r--r-- 1 root staff 5 Dec 9 13:18 file.1 owner@:rw-p--aARWcCos:---:allow group@:r-a-R-c--s:---:allow everyone@:r-a-R-c--s:---:allow File with a mode of 0777: -rwxrwxrwx 1 root staff 5 Dec 9 13:18 file.1 owner@:rwxp--aARWcCos:---:allow group@:rwxp--a-R-c--s:---:allow everyone@:rwxp--a-R-c--s:---:allow File with a mode of 0466: -r--rw-rw- 1 root staff 5 Dec 9 13:18 file.1 owner@:-w:---:deny owner@:r-aARWcCos:---:allow group@:rw-p--a-R-c--s:---:allow everyone@:rw-p--a-R-c--s:---:allow Deny entry is required to prevent owner from picking up write permission from the group@ or everyone@ entry. File with a mode of 0447: -r--r--rwx 1 root staff 5 Dec 9 13:18
Improved ACL interoperability [PSARC/2010/029 FastTrack timeout 02/02/2010]
This all makes perfect sense to me and will assist user understanding and interoperability. I think the only real visible change for most people is that chmod(2) with traditional unix perms will remove the ACL. That might be surprising in some cases, but I can't at the current time think of any applications that would depend on using chmod(2) while preserving an ACL - since most apps don't know about ACLs and most apps (rather than code system utils) don't call chmod(2). So I'm happy with this and it gets my +1. -- Darren J Moffat
Improved ACL interoperability [PSARC/2010/029 FastTrack timeout 02/02/2010]
Tim Haley wrote: File with a mode of 0466: -r--rw-rw- 1 root staff 5 Dec 9 13:18 file.1 owner@:-w:---:deny owner@:r-aARWcCos:---:allow group@:rw-p--a-R-c--s:---:allow everyone@:rw-p--a-R-c--s:---:allow Deny entry is required to prevent owner from picking up write permission from the group@ or everyone@ entry. File with a mode of 0447: -r--r--rwx 1 root staff 5 Dec 9 13:18 file.1 owner@:-wx---:---:deny group@:-wx---:---:deny owner@:r-aARWcCos:---:allow group@:r-a-R-c--s:---:allow everyone@:rwxp--a-R-c--s:---:allow Deny entries are needed for both owner@ and group@ entries to prevent the owner or group owner from picking up write/execute permission from the everyone@ entry. Just to confirm, the examples above are the same regardless of whether or not the owner is a member of the group, right? [Even if the owner is not a group member at the time that the ACE's are created, he could be in the future.] Scott -- Scott Rotondo Principal Engineer, Solaris Security Technologies President, Trusted Computing Group Phone/FAX: +1 408 850 3655 (Internal x68278)
Improved ACL interoperability [PSARC/2010/029 FastTrack timeout 02/02/2010]
Presumably in aclinherit=passthrough-x mode if the new ACL has no @owner/@group ACEs but has ACEs for the file's owner/group then the requested mode_t will be applied to those ACEs? Or is aclinherit=passthrough-x mode left unchanged? Nico --
Improved ACL interoperability [PSARC/2010/029 FastTrack timeout 02/02/2010]
On Jan 26, 2010, at 9:19 AM, Tim Haley wrote: ... ACE Inheritance Parent directory has the following ACL: drwxr-xr-x+ 2 root root 2 Dec 9 14:18 dir.1 user:marks:rwxp--:fd-:allow owner@:rwxp--aARWcCos:---:allow group@:r-x---a-R-c--s:---:allow everyone@:r-x---a-R-c--s:---:allow A simple file create in directory dir.1 will result in the following ACL: # touch file.1 # ls -V file.1 -rw-r--r--+ 1 root root 0 Dec 9 14:20 file.1 user:marks:r-:--I:allow owner@:rw-p--aARWcCos:---:allow group@:r-a-R-c--s:---:allow everyone@:r-a-R-c--s:---:allow The inherited ACE for marks was reduced to be no greater than the group permissions because the aclmode property is set to restricted. If the aclinherit property was set to passthrough then the inherited permissions for marks would have been rwxp. A nit: aclmode in the text quoted above should be aclinherit, right? -- Glenn
Improved ACL interoperability [PSARC/2010/029 FastTrack timeout 02/02/2010]
On Jan 26, 2010, at 9:19 AM, Tim Haley wrote: ... ACE Inheritance Parent directory has the following ACL: drwxr-xr-x+ 2 root root 2 Dec 9 14:18 dir.1 user:marks:rwxp--:fd-:allow owner@:rwxp--aARWcCos:---:allow group@:r-x---a-R-c--s:---:allow everyone@:r-x---a-R-c--s:---:allow A simple file create in directory dir.1 will result in the following ACL: # touch file.1 # ls -V file.1 -rw-r--r--+ 1 root root 0 Dec 9 14:20 file.1 user:marks:r-:--I:allow owner@:rw-p--aARWcCos:---:allow group@:r-a-R-c--s:---:allow everyone@:r-a-R-c--s:---:allow The inherited ACE for marks was reduced to be no greater than the group permissions because the aclmode property is set to restricted. If the aclinherit property was set to passthrough then the inherited permissions for marks would have been rwxp. A nit: aclmode in the text quoted above should be aclinherit, right? Yes, that should have been aclinherit -- Glenn ___ opensolaris-arc mailing list opensolaris-arc at opensolaris.org -- This message posted from opensolaris.org
SPARC support for Fast Reboot [PSARC/2010/030 Self Review]
On 01/26/10 04:52 PM, Huay-Yong Wang wrote: are only available for x86 platforms (See PSARC 2008/382 Fast Reboot) Note that the -e option (boot environments) is not yet supported on SPARC. This project introduces no new interface and I believe this qualify as self-review. I will be marking the case closed approved automatic. If anyone feels that this need to be promoted to a fast track please let me know. The project team is requesting a patch/micro release binding. An updated reboot(1M) manpage is included here. Yay! +100! - Garrett
PSARC/2010/022 Linker-editors: Symbol Capabilities
On 01/26/10 06:03 AM, Rainer Orth wrote: Rod EvansRod.Evans at sun.com writes: The compiler engineers have also asked for a means of selecting between a family of functions contained within the same dynamic object. Each family member is compiled differently to use various capabilities, where these capabilities can be provided by different systems. Not this case, but how is one supposed to use this directly from the compiler/assembler without linker mapfiles? Might be interesting to add support to GCC in the future. The exact method would be up to the compilers. The high-level idea was that some new compiler option(s) might lead the compiler to generate one or more variants of the functions within a source file. For example, if a source file contained foo(), they might generate a foo%sun4u and foo%sun4v, and associate each function with a set of capabilities that were directed by the compilers options. The generated source file would have the same ELF infrastructure as a relocatable object generated with -z symbolcap. ld(1) could then process this file, as it does now with -z symbolcap generated files, and create the associated dynamic object - no mapfiles need be involved. A couple of other questions: * You're currently using v1 mapfile syntax in the LLM excerpt. I suppose this is because this case requests patch/micro binding, but it should state the v2 syntax, too. You've caught us in the middle of two projects, the symbol capabilities and the new mapfile implementation (PSARC/2009/688). The LLM materials for this case don't include changes for 2009/688. However, we have updates for the LLM for 2009/688, and they are being merged together as we speak. The final LLM will have all examples using the v2 syntax. Symbol capabilities can be driven off of v1 or v2 mapfile syntax. * In the example on p.76 of the LLM, what happens if the machine provides e.g. both MMX and SSE. Which instance of foo will be used in this case? I suppose there is a similar ordering like the one described on p.380 (descending order of capability values), but is this supposed to be documented or implementation defined? It should be clearer than it is :-) The largest value wins. * Does LD_CAP_FILES match the file names of shared objects, or their SONAMEs, exact or substring match? The doc states: The most flexible means of defining LD_CAP_FILES is to use the base name of the required files. $ LD_HWCAP=-sse2 LD_CAP_FILES=libfoo.so,libbar.so ./main The files base name is the SONAME. The implementation actually uses the base name, full path name, or even alias names (symlinks) to match any LD_CAP_FILES requirements. -- Rod. Everybody to Everest! April 2010, I'll climb to Mt. Everest Base Camp as a fund raiser for The Challenged Athletes Foundation - www.everybodytoeverest.com. Visit www.everestchallenge.kintera.org/rie to show your support. Thanks!
Improved ACL interoperability [PSARC/2010/029 FastTrack timeout 02/02/2010]
On 01/26/10 12:46 PM, Scott Rotondo wrote: Tim Haley wrote: File with a mode of 0466: -r--rw-rw- 1 root staff 5 Dec 9 13:18 file.1 owner@:-w:---:deny owner@:r-aARWcCos:---:allow group@:rw-p--a-R-c--s:---:allow everyone@:rw-p--a-R-c--s:---:allow Deny entry is required to prevent owner from picking up write permission from the group@ or everyone@ entry. File with a mode of 0447: -r--r--rwx 1 root staff 5 Dec 9 13:18 file.1 owner@:-wx---:---:deny group@:-wx---:---:deny owner@:r-aARWcCos:---:allow group@:r-a-R-c--s:---:allow everyone@:rwxp--a-R-c--s:---:allow Deny entries are needed for both owner@ and group@ entries to prevent the owner or group owner from picking up write/execute permission from the everyone@ entry. Just to confirm, the examples above are the same regardless of whether or not the owner is a member of the group, right? [Even if the owner is not a group member at the time that the ACE's are created, he could be in the future.] Yes Scott
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? Could a generic call identify the virtualization technology, and then, if needed, technology specific queries could be made? -- Rick After discussions with the Xen group, I have reworked this proposal to cater to Xen (and other virtualization technologies) implementing this. This involved mostly name changes (e.g. libldoms in the original proposal is now libv12n, function names are now v12n_* rather than ldoms_*, and manifest constants are now V12N_*) and new bit(s) in the v12n_capabilities function to return virtualization implementation technology. The case materials in the directory have been updated and attached is the new case. Thanks. Mike -- next part -- An embedded and charset-unspecified text was scrubbed... Name: virtinfo.arc URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20100126/1963e406/attachment-0001.ksh
SPARC support for Fast Reboot [PSARC/2010/030 Self Review]
I am sponsoring this fasttrack for Chris Kiick. This project implements fast reboot support for SPARC. Specifically, the -f and -p options in reboot(1M) is now supported on SPARC. Previously these options are only available for x86 platforms (See PSARC 2008/382 Fast Reboot) Note that the -e option (boot environments) is not yet supported on SPARC. This project introduces no new interface and I believe this qualify as self-review. I will be marking the case closed approved automatic. If anyone feels that this need to be promoted to a fast track please let me know. The project team is requesting a patch/micro release binding. An updated reboot(1M) manpage is included here. --- cut here --- System Administration Commands reboot(1M) NAME reboot - restart the operating system SYNOPSIS /usr/sbin/reboot [-dlnq] [-f | -p] [boot_arguments] /usr/sbin/reboot [-f [-e environment] | -p] [-dlnq] [boot_arguments] DESCRIPTION The reboot utility restarts the kernel. The kernel is loaded into memory by the PROM monitor, which transfers control to the loaded kernel. On x86 systems, when the -f flag is specified, the running kernel will load the next kernel into memory, then transfer control to the newly loaded kernel. This form of reboot is shown in the second synopsis, above. Although reboot can be run by the super-user at any time, shutdown(1M) is normally used first to warn all users logged in of the impending loss of service. See shutdown(1M) for details. The reboot utility performs a sync(1M) operation on the disks, and then a multi-user reboot is initiated. See init(1M) for details. On x86 systems, reboot may also update the boot archive as needed to ensure a successful reboot. The reboot utility normally logs the reboot to the system log daemon, syslogd(1M), and places a shutdown record in the login accounting file /var/adm/wtmpx. These actions are inhibited if the -n or -q options are present. Normally, the system reboots itself at power-up or after crashes. OPTIONS The following options are supported: -d Force a system crash dump before rebooting. See dumpadm(1M) for information on configuring system crash dumps. SunOS 5.11 Last change: 26 Jan 20101 System Administration Commands reboot(1M) -e If -f is present, reboot to the specified boot environ- ment. This option is currently available only on x86 systems. -f For x86 systems: Fast reboot, bypassing firmware and boot loader. The new kernel will be loaded into memory by the running kernel, and control will be transferred to the newly loaded ker- nel. If disk or kernel arguments are specified, they must be specified before other boot arguments. For SPARC systems: Speeds up rebooting by skipping some POST tests. The service svc:/system/boot-config:default is enabled by default. It requires solaris.system.shutdown as action_authorization and value_authorization. When the config/fastreboot_default property is set to true, reboot will behave as reboot -f. The value of this pro- perty can be changed using svccfg(1M) and svcadm(1M), to control the default reboot behavior. See EXAMPLES for details. -l Suppress sending a message to the system log daemon, syslogd(1M) about who executed reboot. -n Avoid calling sync(2) and do not log the reboot to syslogd(1M) or to /var/adm/wtmpx. The kernel still attempts to sync filesystems prior to reboot, except if the -d option is also present. If -d is used with -n, the kernel does not attempt to sync file systems. -p Reboot to prom. This flag can be used to reboot the sys- tem through firmware without changing the default reboot SunOS 5.11 Last change: 26 Jan 20102 System Administration Commands reboot(1M) behavior as denoted by the config/fastreboot_default property setting in system/boot-config service. The -p and -f options are mutually exclusive. -q Quick. Reboot quickly and ungracefully, without shutting down running processes first. OPERANDS The following operands are supported: boot_arguments An optional boot_arguments specifies arguments to the uadmin(2) function that are passed to the boot program and kernel upon restart. The form and list of arguments is described in the boot(1M) and kernel(1M) man
