Re: [osol-discuss] IA64laris, anyone ? (an RFC)
On Nov 11, 2007 3:36 AM, John Sonnenschein [EMAIL PROTECTED] wrote: Is anyone other than myself interested in seeing an IA64/Itanium port of OpenSolaris? My reasoning is that Solaris already runs on two of the 4 major enterprise architectures (SPARC x86/amd64) and a port to a third is making strides recently ( I'm referring to the ppc32 port ). Since Sun already had an IA64 port underway half a decade ago, they may be able to look in to the legalities of opening it back up. I'm sure there's some sort of legal wrangling between them and Intel that can go on, since Intel would undoubtedly love to see more ia64 customers, and Sun already sells Solaris to HP's x86 customers. Failing that, of course, if anyone's interested in doing a straight-up re-port based on the current onnv-gate ( or ppc-dev gate, if that proves to be more portable ) that's an option as well. This port may actually prove easier logistically than the PPC port, as there's already an accurate ia64 simulator ( it's called ski ) out there, though it only runs on HPUX, Linux ( I haven't tried it with brandZ ) FreeBSD. So, that in mind, any comments? The project will not have a chance. The Solaris/IA64 project was canceled by the board after Intel announced that IA64 will replace SPARC and NOTHING will reverse that decision, not even the new Intel-Sun alliance. Even without the history I'd be a tough job to get the old Solaris/IA64 sources - we tried to convince the high-end platform group to release their sources for the 64k kernel project and invited them to join a research project lead by TU Vienna and sponsored with EU money. Sun rejected this high profile offer, even after offering free licenses for any patents created during this project. I doubt you'd have more luck with IA64. Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] IA64laris, anyone ? (an RFC)
On Nov 12, 2007 6:01 PM, Shawn Walker [EMAIL PROTECTED] wrote: On 12/11/2007, Holger Berger [EMAIL PROTECTED] wrote: On Nov 11, 2007 3:36 AM, John Sonnenschein [EMAIL PROTECTED] wrote: Is anyone other than myself interested in seeing an IA64/Itanium port of OpenSolaris? My reasoning is that Solaris already runs on two of the 4 major enterprise architectures (SPARC x86/amd64) and a port to a third is making strides recently ( I'm referring to the ppc32 port ). Since Sun already had an IA64 port underway half a decade ago, they may be able to look in to the legalities of opening it back up. I'm sure there's some sort of legal wrangling between them and Intel that can go on, since Intel would undoubtedly love to see more ia64 customers, and Sun already sells Solaris to HP's x86 customers. Failing that, of course, if anyone's interested in doing a straight-up re-port based on the current onnv-gate ( or ppc-dev gate, if that proves to be more portable ) that's an option as well. This port may actually prove easier logistically than the PPC port, as there's already an accurate ia64 simulator ( it's called ski ) out there, though it only runs on HPUX, Linux ( I haven't tried it with brandZ ) FreeBSD. So, that in mind, any comments? The project will not have a chance. The Solaris/IA64 project was The source code is open and no one can stop such a thing from happening; Sun may not have any desire to help and may actively not help at all. So, actually, the project has a very good chance of succeeding. There are no rules to prevent integration of said source code either. Unlike the Polaris project you'd have to start from scratch, without sources of a previous project. You don't have machines or funding either, right? Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] VMware published under GPL
Would it help to ask for a joint Opensolaris.org/VMware project to port the host OS kernel modules to Opensolaris? On 9/12/07, Andy Tucker [EMAIL PROTECTED] wrote: Joerg writes: Hi Andy, this reads as if there are plans to add kernel components for Solaris and FreeBSD allowing to use these OS as Host OS in future. Id this correct? I was just talking about the drivers that run in the guest VM when tools are installed (currently vmxnet, vmmemctl, vmblock, and vmhgfs). The drivers that need to be installed in the host OS to run the hosted products (vmmon and vmnet) are a separate issue. I'm not aware of any plans to port the host drivers to Solaris or FreeBSD (though we've certainly had requests). This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Compiler mailing list?
On 6/15/07, Holger Berger [EMAIL PROTECTED] wrote: On 6/11/07, Kuldip Oberoi [EMAIL PROTECTED] wrote: Well, the answer, historically, is to point folks to the tools community (5+ forums) on SDN that the Sun Studio product team monitors: http://forum.java.sun.com/category.jspa?categoryID=113 Now, there has been feedback that the SDN forum mechanism, w/o the email gateway, is less than adequate in terms of usability. That feedback has made the SDN forum mgmt team and I've asked them for a roadmap which includes this gateway feature. Did the mgmt team respond? Kuldip? Did the mgmt team respond? Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] C-team, and ON aliases
On 6/21/07, Stephen Lau [EMAIL PROTECTED] wrote: A couple of months ago, Mark (on behalf of the C-Team, I believe) suggested reorganising the ON community, onnv project, and associated mailing lists. http://mail.opensolaris.org/pipermail/opensolaris-discuss/2007-April/027086.html Whatever happened with this? Should we go ahead and implement the changes suggested? If you change the list structure please add the requested compiler list. Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Compiler mailing list?
On 6/11/07, Kuldip Oberoi [EMAIL PROTECTED] wrote: Well, the answer, historically, is to point folks to the tools community (5+ forums) on SDN that the Sun Studio product team monitors: http://forum.java.sun.com/category.jspa?categoryID=113 Now, there has been feedback that the SDN forum mechanism, w/o the email gateway, is less than adequate in terms of usability. That feedback has made the SDN forum mgmt team and I've asked them for a roadmap which includes this gateway feature. Did the mgmt team respond? Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project Proposal: SAM-QFS
On 4/24/07, Ted Pogue [EMAIL PROTECTED] wrote: Project Overview: I propose the creation of a project on opensolaris.org, to bring to the community Solaris host-based data services; namely the Storage Archive Manager or SAM and the Solaris shared file system QFS. These data services exist today and are distributed commercially by Sun as the Sun StorageTek Storage Archive Manager and Sun StorageTek QFS shared file system. The software is delivered unbundled commercially for Solaris 9 and 10, but also is compiled for and runs on Open Solaris. Ted, when will this project go public? Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Compiler mailing list?
On 5/15/07, Alan Coopersmith [EMAIL PROTECTED] wrote: Bruno Jargot wrote: Does Opensolaris have mailing list for the Studio compiler (mailing list, not the dreaded web forum Sun uses for support)? You might find some help on tools-discuss, but the Studio compiler isn't really part of the OpenSolaris project, and they seem to like their web forums on developers.sun.com. The Sun Studio compiler is still a central piece for Opensolaris development. Since Sun is unlikely to replace the web forum interface in the near future I support the request to create a mailing list on opensolaris.org Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Compiler mailing list?
On 5/18/07, Brian Gupta [EMAIL PROTECTED] wrote: The Sun Studio compiler is still a central piece for Opensolaris development. Since Sun is unlikely to replace the web forum interface in the near future I support the request to create a mailing list on opensolaris.org Might this fall under tools-discuss? tools-discuss is AFAIK for Nevada build tools only. Sun Studio has a wider scope. Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project Proposal: SAM-QFS
On 4/24/07, Joerg Schilling [EMAIL PROTECTED] wrote: Ted Pogue [EMAIL PROTECTED] wrote: Project Overview: I propose the creation of a project on opensolaris.org, to bring to the community Solaris host-based data services; namely the Storage Archive Manager or SAM and the Solaris shared file system QFS. These data services exist today and are distributed commercially by Sun as the Sun StorageTek Storage Archive Manager and Sun StorageTek QFS shared file system. The software is delivered unbundled commercially for Solaris 9 and 10, but also is compiled for and runs on Open Solaris. While doing this is a really good idea, I see potential name conflicts with older softare. Since 20..25 years, I create and publish programs like: smake, star, sformat, sfind (a bit newer), I think it is better to rename such tools to schillymake, schillytar, schillyformat or put them into usr/schilly/bin. Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project Proposal: SAM-QFS
On 4/24/07, Tom Haynes [EMAIL PROTECTED] wrote: Joerg Schilling wrote: Ted Pogue [EMAIL PROTECTED] wrote: Project Overview: I propose the creation of a project on opensolaris.org, to bring to the community Solaris host-based data services; namely the Storage Archive Manager or SAM and the Solaris shared file system QFS. These data services exist today and are distributed commercially by Sun as the Sun StorageTek Storage Archive Manager and Sun StorageTek QFS shared file system. The software is delivered unbundled commercially for Solaris 9 and 10, but also is compiled for and runs on Open Solaris. While doing this is a really good idea, I see potential name conflicts with older softare. Since 20..25 years, I create and publish programs like: smake, star, sformat, sfind (a bit newer), and I recently got some information that SAMFS may include progran names like star and sfind. I support this project, but I would like to see that the programs are renamed into something like: 'sam*' in order to avoid confusion. Jörg Considering these are currently unbundled and shipping products, that might be hard. I.e., would you want to tell customers that they need to learn new commands, change all of their scripts, etc? I agree. May be better to put the Schilly tools into a separate directory (/usr/schilly/bin) or rename them. Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project Proposal: SAM-QFS
On 4/24/07, Joerg Schilling [EMAIL PROTECTED] wrote: Tom Haynes [EMAIL PROTECTED] wrote: Considering these are currently unbundled and shipping products, that might be hard. I.e., would you want to tell customers that they need to learn new commands, change all of their scripts, etc? Does this mean that my fears are correct? Consdering the fact that a lot more people know the real star and that there is already an aproved ARC case to integrate star into /usr/bin, would you like to confuse customers? I think renaming the existing samfs tools would be more confusing. Backwards compatibility is more important than name collisions with a tool (star) which does not ship with Solaris yet. Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project Proposal: SAM-QFS
On 4/24/07, Ted Pogue [EMAIL PROTECTED] wrote: Project Overview: I propose the creation of a project on opensolaris.org, to bring to the community Solaris host-based data services; namely the Storage Archive Manager or SAM and the Solaris shared file system QFS. These data services exist today and are distributed commercially by Sun as the Sun StorageTek Storage Archive Manager and Sun StorageTek QFS shared file system. The software is delivered unbundled commercially for Solaris 9 and 10, but also is compiled for and runs on Open Solaris. +1 Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [website-discuss] java.lang.NullPointerException in Forums
On 1/25/07, Glynn Foster [EMAIL PROTECTED] wrote: Derek Cicero wrote: If we can't get the forums into a reasonable state after the upgrade we will look into removing Jive from site completely and finding a lightweight replacement to allow users to view and search the mail archives as well as provide a posting facility for registered users. +1 +1 for killing Jive. Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Refined OpenSolaris KDE proposal / Re: Proposal to create an OpenSolaris KDE project
On 1/17/07, Eric Boutilier [EMAIL PROTECTED] wrote: Need clarification please. Are John Sonnenschein and Roland Mainz co-owners of the KDE proposal now? I remember the day when it was considered 'impossible' to convince Sun to introduce ksh93 to Solaris and somehow Roland Mainz managed to get ksh93 into Solaris. Currently most of us consider it 'impossible' that KDE makes it into Solaris. I'd like to nominate Roland Mainz as project lead for the (Open)Solaris KDE project, maybe he can do the 'impossible' again. Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Project proposal: 64k kernel project
Project proposal: 64k kernel project I propose a 64k kernel project. This project should contribute and support on an on-going basis: - A SPARC kernel which uses 64k pages instead of 8k pages (dwarf pages) as default page size. The system should no longer use or support the usage of 8k pages - Necessary modifications to kernel modules to support the 64k page size mode (notable usage of hard coded 8k page size exists for example in the UFS module) - Necessary modifications to user land tools in ON to support the kernel 64k page size mode - Create the tools necessary to create, maintain and profile the kernel performance. The leaders initially will be Knut Reinert and myself. This project proposal has one (large) problem: We can only start this project if Sun is willing to contribute the changes of their own (abandoned) 64k kernel project - is this possible? Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project proposal: 64k kernel project
On 10/9/06, Paul Durrant [EMAIL PROTECTED] wrote: On 10/9/06, Holger Berger [EMAIL PROTECTED] wrote: Project proposal: 64k kernel project I propose a 64k kernel project. This project should contribute and support on an on-going basis: - A SPARC kernel which uses 64k pages instead of 8k pages (dwarf pages) as default page size. The system should no longer use or support the usage of 8k pages How would this work with network I/O? Do the IOMMUs support 64k pages? AFAIK yes Do you really want to expose a 64k chunk of memory to IO just to DMA in a single ethernet packet? These are static buffers. We know that *some* memory gets wasted but the amount should be limited Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Community Proposal: HPC Developer
On 10/3/06, Akhilesh Mritunjai [EMAIL PROTECTED] wrote: Most of the projects fall under the category of 'useful but not really product level' tools. As far as I understand, people dealing with HPC, don't mind playing with useful tools, but they sure do appreciate having full blown products so they can concentrate on the real issues. Now, opensolaris groups seem to be just the right kind of places where ideas-in-making are incubated so they can turn into full blown products with time, and I'm sure SUN can do better with full blown HPC products now that hundred teraflop computers are being commissioned by them :-) I'd say, bring it on... +1 +1 Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: IA64 port?
On 8/27/06, Fabian Wörner [EMAIL PROTECTED] wrote: there was a ia64 port in the lab http://www.heise.de/newsticker/meldung/6668 We could revive the IA64 port (excluding the now obsolete IA32 emulation bits; the IA64 port of Solaris should strictly be 64bit only) if Sun/Intel would be willing to release enough source code from the 1999/2000 time frame to create a system which is able to boot. Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Obtaining Error Return Status when using rsh remote command execution
On 8/22/06, Mark Phalan [EMAIL PROTECTED] wrote: On Tue, 2006-08-22 at 20:44 +0800, Steven Sim wrote: Hey Gurus; FORGIVE me if this is not the place to post this small scripting issue. I wish to run the following Korn shell command in a script rsh -n -l user remote-host cksum file if [[ $? -ne 0 ]]; statements fi The above would not successfully capture an error condition if file did not exist in the remote server.. The remote rsh execution facility does not return the exit code of the remote command. Any ideas? Why not use ssh? ssh needs some time to connect and adds significant latency to the connection. This may not be desired in some applications -- Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] How to deal with Studio 11 cc compiler performance?
On 8/22/06, Kuldip Oberoi [EMAIL PROTECTED] wrote: Hi Joerg, There are a few methods to provide feedback to the product team: 1. Sun Developer Service Plans/Sun Support Services Plans ($$) developers.sun.com/services This offers the official bug escalation process. 2. Bug Submittal (free) http://bugs.sun.com Report a bug. The team will see it, but it will not necessarily be escalated for a priority fix. In addition, there are a few additional mechanisms for support: 3. Sun Developer Expert Assistance ($) http://developers.sun.com/services/expertassistance/ Incident level support- help review flags, etc. 4. Sun Studio forums (free) http://developers.sun.com/prodtech/cc/community/ Community forums. Of courses, in all cases, it is helpful to have example code, makefile, etc. to help illustrate the issue. The Community forums are a pain to use. I wish you would listen to the requests and replace them with a normal mailman mailing list. -- Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Subversion in Solaris / was: Re: [osol-discuss] Re: [tools-discuss] Distributed source codemanagement selection, draft
On 5/5/06, Joerg Schilling [EMAIL PROTECTED] wrote: Holger Berger [EMAIL PROTECTED] wrote: What if the application is the shell itself? The shell cannot access This is not really true. the shell may access the files after it has been started using runat(1) or in case you did 'cd -@ file' on a xattrs enabled shell. Is there **ANY** shell which actually supports this amyelencephalus? those files and many tools dump core when used via runat(1). I'd say The applicartions that dump core rhn run via runat(1) are broken and need to be fixed. Note that they will dump also core when used in a non XATTR environment but only with a lower probability. Feel free to fix Open Office, the java runtime, tex, gnome-terminal, lp, ddd, mplayer, ghostscript and likely a lot of other applications and utilities. And I assume which single shell script provided with Solaris needs to be fixed, too. the current XATTR implementation is doomed - and at least the Linux kernel developers agree with that. So far they don't plan to extend that voyage and the patches for the kernel are put aside indefinitely (Suse and Red Hat even have patches to remove the existing parts from their kernel versions). Please don't try to use arguments from Linux kernel developers to prove your statements. Please don't try to be so snobbish and ignore the expertise and exceptions of the Linux and BSD people. They have valid arguments against the Solaris implementation and you still have to prove that my exceptions about the shell usage are not important. Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Subversion in Solaris / was: Re: [osol-discuss] Re: [tools-discuss] Distributed source codemanagement selection, draft
On 5/5/06, Joerg Schilling [EMAIL PROTECTED] wrote: Holger Berger [EMAIL PROTECTED] wrote: The problem I see that these extended attributes are inaccessible from within normal applications and the provided kludges such as Why do you believe this? The shell has no access to these files. runat(1) are not usable outside a lab environment. First at all these extended attribute files need to be made accessible in the normal file system name space, otherwise it is just wasted time to deal with them. Roland proposed to implement cd -@ file in addition to runat(1). In which list was this amyelencephalus proposed? Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Subversion in Solaris / was: Re: [osol-discuss] Re: [tools-discuss] Distributed source codemanagement selection, draft
On 5/5/06, Joerg Schilling [EMAIL PROTECTED] wrote: Holger Berger [EMAIL PROTECTED] wrote: 1) Linux FreeBSD currently work on a full NFSv4 implementation that includes the NFSv4 XATTE interface which is the base of the Solaris XATTR interface. Linux will support NFSv4 fully - without the XATTR extensions. The XATTR support is suspended indefinitely. Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Subversion in Solaris / was: Re: [osol-discuss] Re: [tools-discuss] Distributed source codemanagement selection, draft
On 5/2/06, Darren J Moffat [EMAIL PROTECTED] wrote: Robert Thurlow wrote: I don't agree with Darren that runat is a problem, and it's in the wild, so I don't expect it to go anywhere. Let me clarify what I meant by my statement. I think runat(1) is a good debug/development tool. I don't believe that it is useful for building applications on top of, if you need to build apps then use openat(2) and friends not shell scripting. Please relocate the tool to /sbin/runat to make clear it is only intended to be used for administrative purposes. Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: XATTRs
On 5/5/06, Darren J Moffat [EMAIL PROTECTED] wrote: Holger Berger wrote: On 5/5/06, Joerg Schilling [EMAIL PROTECTED] wrote: Holger Berger [EMAIL PROTECTED] wrote: What if the application is the shell itself? The shell cannot access This is not really true. the shell may access the files after it has been started using runat(1) or in case you did 'cd -@ file' on a xattrs enabled shell. Is there **ANY** shell which actually supports this amyelencephalus? What is that word you keep using I can't find a definition for it. It is a medical term, a rare defect during fetus development. Such children are lacking brain and spinal cord. They usually die within less than a month after birth. Can you please stick to plain simple English. I'm a native English speaker and I can't follow what you mean, there are lots of people on this list who are not native speakers. Please don't try to be so snobbish and ignore the expertise and Please give DETAILS rather than just unsupported statements. There is no way for a shell script to read, write, rename or delete an attribute file. Applications without special support for the openat() API have no way to access the files either. All utilities, including those needed for backup and administration, need to be made XATTR aware - something which is unique in the whole history of Unix. No other file system change required such a drastic step yet. Applications started with runat(1) do not have a proper parent directory which confuses most applications and causes crashes. Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Subversion in Solaris / was: Re: [osol-discuss] Re: [tools-discuss] Distributed source codemanagement selection, draft
On 5/5/06, Joerg Schilling [EMAIL PROTECTED] wrote: Holger Berger [EMAIL PROTECTED] wrote: On 5/5/06, Joerg Schilling [EMAIL PROTECTED] wrote: Holger Berger [EMAIL PROTECTED] wrote: 1) Linux FreeBSD currently work on a full NFSv4 implementation that includes the NFSv4 XATTE interface which is the base of the Solaris XATTR interface. Linux will support NFSv4 fully - without the XATTR extensions. The XATTR support is suspended indefinitely. Wrong: I encourtage you to talk to the people who are working on the project. Unless they did change their mind recently, they are still working on support for XATTRs. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily I asked the Novell kernel engineers at LinuxTag in Wiesbaden. Neither Novell/Suse or Red Hat will support the NFSv4 version of XATTR in the foreseeable future. Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Build times for Open Solaris....
On 4/18/06, Menno Lageman [EMAIL PROTECTED] wrote: Holger Berger wrote: I think one part of this jigsaw is the disk bottleneck. If you build ON on a tmpfs volume you should have a far better CPU utilisation on Niagara. Nothing beats real data, so I ran a nightly on a tmpfs file system with max jobs = 32. The build time decreases from 1:53 (on UFS) to 1:45. It helps, but only slightly (as expected). I tried it myself - with different results: Built time with UFS is 1:42h and decreases to 1:08h with tmpfs (swap device is on a different spindle and the T2000 has the memory maxed out). Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Subversion in Solaris / was: Re: [osol-discuss] Re: [tools-discuss] Distributed source codemanagement selection, draft
On 4/10/06, Roland Mainz [EMAIL PROTECTED] wrote: Stephen Hahn wrote: One of the upcoming submissions for the freeware consolidation will be to ensure that Subversion and Mercurial are available in one or more of the standard installation scenarios. Where will subversion be located ? I hope it's /usr/ccs/bin/ like all the other development stuff... BTW: When subversion will become a part of Solaris I'd like to propose a project which looks at some platform-specific optimisations for subversion, including some hacks to libsvn_wc (the code which handles the subversion working copy) to make it faster and employ XATTR files instead of the .svn/ directories... I think this is wasted time. The whole XATTR API is brain dead and should IMHO be depreciated in favor of a extension which will allow all applications to access such attribute files. You should also take into consideration that the XATTR API will not be supported on any other operating systems in the foreseeable future due its brokenness. Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] ld.so refuses to properly handle paths with colon
On 4/30/06, Rod Evans [EMAIL PROTECTED] wrote: The colon has been the standard separator of multiple pathnames within the link-editing environment since Solaris 2.0 (it was even used in Solaris 1 (4.x) if I recall). Is there a way to override, replace or escape the ':' separator? Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Main OS/Net repository - based on Subversion or Mercurial ? / was: Re: [osol-discuss] Re: [tools-discuss] Distributed source codemanagement selection, draft
On 4/28/06, Stephen Lau [EMAIL PROTECTED] wrote: Roland Mainz wrote: Stephen Hahn wrote: The plan of record for hosting source code is to support Subversion and (now) Mercurial as a per-repository choice, so there's no freeze out for projects that believe they require Subversion for their tools. The primary consolidation driving the distributed SCM choice is ON; there are no tools constraints of the kind you mention upon contributors to ON. What does that mean for ON - will the main OS/Net repository on opensolaris.org be based on Subversion or on Mercurial ? Mercurial. I think this choice is very very bad. Almost no utility software supports Mercurial which will not be very attractive to developers. You've chosen a niece product which nearly zero support (excluding the Mercurial developers themselves) in the open source community - which may be a factor which was not taken into account in the original evaluation. Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Subversion in Solaris / was: Re: [osol-discuss] Re: [tools-discuss] Distributed source codemanagement selection, draft
On 5/2/06, Darren J Moffat [EMAIL PROTECTED] wrote: Holger Berger wrote: On 4/10/06, Roland Mainz [EMAIL PROTECTED] wrote: Stephen Hahn wrote: One of the upcoming submissions for the freeware consolidation will be to ensure that Subversion and Mercurial are available in one or more of the standard installation scenarios. Where will subversion be located ? I hope it's /usr/ccs/bin/ like all the other development stuff... BTW: When subversion will become a part of Solaris I'd like to propose a project which looks at some platform-specific optimisations for subversion, including some hacks to libsvn_wc (the code which handles the subversion working copy) to make it faster and employ XATTR files instead of the .svn/ directories... I don't believe it will actually make it go faster since XATTR files are just files in a special directory at the end of the day. I think this is wasted time. The whole XATTR API is brain dead and should IMHO be depreciated in favor of a extension which will allow all applications to access such attribute files. You should also take into consideration that the XATTR API will not be supported on any other operating systems in the foreseeable future due its brokenness. So if it is just the API that is broken we can fix that. Apple's HFS+ has extended attributes as well and uses them quite heavily as far as I can tell. Their API is different to the openat(2) that Solaris has though. The problem I see that these extended attributes are inaccessible from within normal applications and the provided kludges such as runat(1) are not usable outside a lab environment. First at all these extended attribute files need to be made accessible in the normal file system name space, otherwise it is just wasted time to deal with them. Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Main OS/Net repository - based on Subversion or Mercurial ? / was: Re: [osol-discuss] Re: [tools-discuss] Distributed source codemanagement selection, draft
On 5/2/06, Dick Davies [EMAIL PROTECTED] wrote: On 02/05/06, Darren J Moffat [EMAIL PROTECTED] wrote: Also I'm sure I heard somewhere else that there was a pretty darn large other open source project also moving to Mercurial, can't remember which one. Xen. Let me guess: Someone from Sun proposed the switch, right? Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Subversion in Solaris / was: Re: [osol-discuss] Re: [tools-discuss] Distributed source codemanagement selection, draft
On 5/2/06, Darren J Moffat [EMAIL PROTECTED] wrote: Holger Berger wrote: The problem I see that these extended attributes are inaccessible from within normal applications and the provided kludges such as runat(1) are not usable outside a lab environment. First at all these extended attribute files need to be made accessible in the normal file system name space, otherwise it is just wasted time to deal with them. The whole point of them is that they aren't part of the normal file system name space. They aren't on MacOS X either as best as I can tell, and I don't believe (though I have no way to check nor the skill to do so) that they are on Windows XP either. They are also fully intended to be application/system specific What if the application is the shell itself? The shell cannot access those files and many tools dump core when used via runat(1). I'd say the current XATTR implementation is doomed - and at least the Linux kernel developers agree with that. So far they don't plan to extend that voyage and the patches for the kernel are put aside indefinitely (Suse and Red Hat even have patches to remove the existing parts from their kernel versions). Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Main OS/Net repository - based on Subversion or Mercurial ? / was: Re: [osol-discuss] Re: [tools-discuss] Distributed source codemanagement selection, draft
On 5/2/06, Darren J Moffat [EMAIL PROTECTED] wrote: Holger Berger wrote: What does that mean for ON - will the main OS/Net repository on opensolaris.org be based on Subversion or on Mercurial ? Mercurial. I think this choice is very very bad. Almost no utility software supports Mercurial which will not be very attractive to developers. You've chosen a niece product which nearly zero support (excluding the Mercurial developers themselves) in the open source community - which may be a factor which was not taken into account in the original evaluation. So if it supports all the functionality we need better than any other product it is still a bad choice ? How so ? Maybe the fact that there is no utility software is an indication that the product is sufficiently complete that none is needed. Hello? I was talking about Mercurial support in other applications such as source browsers, search engines, backup tools, ticket generators, patch signers, splicers, bot and daemon support (for generating RSS feeds, commit emails, firewall and proxy support). Mercurial is supported nowhere while Google returns more than 110 hits for Subversion leaving alone the utilities for CVS. For example Teamware needs ws(1) and wx(1) utility software to be useful for ON development on a large scale but you can cope without them. Also I'm sure I heard somewhere else that there was a pretty darn large other open source project also moving to Mercurial, can't remember which one. FreeBSD was evaluating Mercurial, but the last comments from LinuxTag 2005 indicate that they are stepping back from that idea. Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Subversion in Solaris / was: Re: [osol-discuss] Re: [tools-discuss] Distributed source codemanagement selection, draft
On 5/2/06, Darren J Moffat [EMAIL PROTECTED] wrote: Holger Berger wrote: On 5/2/06, Darren J Moffat [EMAIL PROTECTED] wrote: Holger Berger wrote: The problem I see that these extended attributes are inaccessible from within normal applications and the provided kludges such as runat(1) are not usable outside a lab environment. First at all these extended attribute files need to be made accessible in the normal file system name space, otherwise it is just wasted time to deal with them. The whole point of them is that they aren't part of the normal file system name space. They aren't on MacOS X either as best as I can tell, and I don't believe (though I have no way to check nor the skill to do so) that they are on Windows XP either. They are also fully intended to be application/system specific What if the application is the shell itself? The shell cannot access those files and many tools dump core when used via runat(1). I'd say IMO thats not really what they were intended for. For which specific application was the XATTR API designed for? JDS? It certainly wasn't why they were introduced into Solaris. IMO runat(1) should never have been shipped it presents a strange view of the world and an illusion that something outside of the creating application can and should be able to manipulate the xattrs (which IMO is not necessarily a desireable thing). I agree with you. Could you file a bug to get it removed from the distribution, please? Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Build times for Open Solaris....
On 4/14/06, Menno Lageman [EMAIL PROTECTED] wrote: I happen to have access to a T2000 (1 GHz, 32 strands) for a couple of days, so I ran a nightly of on20050327: Nightly distributed build completed: Thu Apr 13 22:17:16 CEST 2006 Total build time real2:26:51 This was with the default max concurrent jobs = 4. Increasing it to 32 through $HOME/.make.machines did not decrease build time, because the build process is mostly serial as Bart noted earlier. Apart from short periods where 32 concurrent jobs can be seen utilizing the system 100%, the system is mostly idle during the build. This of course makes it a nice shared build machine running, say, 32 builds in parallel. I think one part of this jigsaw is the disk bottleneck. If you build ON on a tmpfs volume you should have a far better CPU utilisation on Niagara. I wish tmpfs would utilise 64k pages instead of the dwarfpages which may even better :-) Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] However, the zfs file system /export/zfs_0 must be shared ?? What ?
On 4/12/06, Darren J Moffat [EMAIL PROTECTED] wrote: So why not have /export/zfs_0/ /export/zfs_0/jumpstart /export/zfs_0/jumpstart/s10 /export/zfs_0/jumpstart/s10/SXCRb35 all as separate ZFS filesystems, they are cheap after all :-) It is still a bug which should be fixed. The requirement that only the base of a ZFS file system can be shared is a serious limitation which will hamper or even prevent deployment of ZFS at large sites. Simplified example: Someone may want to set up shares temporarily in a sub directory and the requirement to create an extra ZFS file system for that is a overkill, if not even a risk for production usage (I consider changes in a file system setup as a far higher risk than letting people share their data via NFS). Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: [tools-discuss] Distributed source code management selection, dra
On 4/8/06, Bryan O'Sullivan [EMAIL PROTECTED] wrote: Hi, Holger - Thanks for raising your concerns. I have some responses below. - Interoperability: Is there a compatibility layer or bridge to make the Mercurial repository available to CVS or Subversion clients? Yes. Lele Gaifax has written a tool called tailor that allows bridging between CVS, Subversion and Mercurial. Is this bridge one way or does it work in both directions? What are the plans for the main repository - will it be based on Mercurial or Subversion? If I recall it correctly Mercurial required Python(!!) which is a portability NIGHTMARE. I'm sure you must have many specifics in mind; would you like to share them? I think that would be very helpful in keeping the discussion grounded in concrete terms. The specifics are various API changed which broke python applications in the past which made me a very unhappy python user (good examples are the i18n changes which broke mailman several times in the past, hitting even big sites such as freedesktop.org and sourceforge). The problem I see that even a minor change in the python run time can cause subtle errors which remain unnoticed for a longer time (the python issue at sourceforge caused a gaping security hole which was exploited within less than a day, making this concern even a security issue). My question at this point is: Does Mercurial provide any test suite and internal consistency checking mechanism to prevent data corruption or spoofing? Will Sun provide precompiled and TESTED python and Mercurial packages? Will be there a security audit at Suns side of the python run time and Mercurial code? For comparison: The Subversion code was already audited by several parties including the German Bundesamt für Sicherheit in der Informationstechnik and certified for usage in sensitive areas within the government. Mercurial was mentioned nowhere in their internal lists - either Mercurial is something brand new or it fell through for other reasons. The latter option worries me (again this may be unjustified - it is just a feeling). - Availability: Neither Suse Linux or any BSD variants (FreeBSD, OpenBSD, NetBSD) provide Mercurial packages as part of their distributions. I'm afraid that none of these claims is actually true. Here are some pointers I found with a few simple Google searches just a moment ago: Here is the NetBSD port (Google for netbsd mercurial): http://pkgsrc.se/devel/mercurial The FreeBSD port (Google for freebsd mercurial ports): http://www.freshports.org/devel/mercurial/ These packages are not on the official distribution CDs. There are ports which compile but there is no guarantee whether they really work. The SUSE package (Google for suse mercurial): http://www.novell.com/products/linuxpackages/professional/mercurial.html Again, yast does not list a package mercurial in Suse 9.1 and 9.2. It is available as optional package for download but it is not part of the official DVD (your link above indicates that it was added for 10.0 which may be a good thing (TM)). -- Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: RFE: /etc/system tuneable tosetthedefaultpagesize
On 3/19/06, Eric Lowe [EMAIL PROTECTED] wrote: Holger Berger wrote: I wasn't directly involved in the 64K prototype but only 64K and larger were used for user applications, and the page_t was 64K in span (PAGESIZE=65536). There may have been some 8K mappings in the kernel due to OBP handing off translation lists with holes -- I don't remember the details there. Who was involved in this project? I don't believe any of the folks involved directly are active in OpenSolaris yet, so to avoid having vegetables thrown at me I won't say. :) Maybe the project lead at Sun is willing to comment here. Could you ask him, please? Did you receive any answers yet? I'd like to write a project proposal for a 64k kernel project - assuming Sun is willing to release the sources of their original prototype. Great -- by all means, go for it! First I'd like to ensure that Sun is willing to contribute the code. A project without a basis is useless. We'll need to figure out which community should own this project long-term. We've been reluctant to build a VM community because several of us feel that a broader kernel community would better facilitate open discussion and collaboration, yet such a community would have significant overlap with existing communities, so that still needs some sorting out. For the time being, I think the Performance community would be a good home for it -- check with the leaders. Ok. perf-discuss@opensolaris.org is now in the CC: :-) I did check into the source issue a little but haven't had the bandwidth to investigate the details yet. The old project gate is based on S9, so we can't just toss it over the wall. If you're open to a partially complete starter solution to seed the work, i.e. which doesn't quite boot and run on all machines but has most of the right areas at least fleshed out, that would probably be much easier for me to push for on my end. I'd be happy if it boots at least via NFS or could be adjusted to boot via NFS quickly. It depends on the application. For the majority of smaller and medium sized applications such as FEM 64k pages have a serious advantage. I/O operations are limited by dwarfpages, too. MPSS buys nothing in this case. Our whole kernel I/O subsystem is not large page aware, which is something that clearly needs work, you're right about that. (And, the fact that the bus nexus internal interfaces are all page-based is a perfect example of why this is so hard to change!) The kernel I/O subsystem does not need to be large file aware. The minimum page size changes from 8k to 64k. By design and definition 64k pages will no longer be large pages at all. This is why I think much less work needs to be done as you think. UFS may need work, MMU core code needs adjustments for the 8k-to-64k transition (see earlier comments) and some tunable need to be changed. That is all for now on the To Do list. -- Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: RFE: /etc/system tuneable tosetthedefaultpagesize
On 3/9/06, Eric Lowe [EMAIL PROTECTED] wrote: The performance analysis was, as I recall, done mostly using US-III+. Did this include the concept that dwarfpages (8k) are no longer available to both kernel and user land applications? I wasn't directly involved in the 64K prototype but only 64K and larger were used for user applications, and the page_t was 64K in span (PAGESIZE=65536). There may have been some 8K mappings in the kernel due to OBP handing off translation lists with holes -- I don't remember the details there. Who was involved in this project? Can Sun release the code? I'd be more than happy to write a project proposal then. I assume we will receive some help from the HPC community. The next generation of vector supercomputers may use similar large page sizes (= 64k) as minimum configurable value and Opensolaris may be a good testbed implementation - assuming we can completely eradicate dwarfpages from kernel and user land. I'll ask around. Did you receive any answers yet? I'd like to write a project proposal for a 64k kernel project - assuming Sun is willing to release the sources of their original prototype. Keep in mind though that just flipping page_t's to be 64K isn't a magic pill; most applications in the HPC space, etc. still need huge pages to fit their working set in the TLB, and spend most or all of their TLB misses on the working data set, so 64K is not likely to be a win at all in that space. It depends on the application. For the majority of smaller and medium sized applications such as FEM 64k pages have a serious advantage. I/O operations are limited by dwarfpages, too. MPSS buys nothing in this case. -- Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: RFE: /etc/system tuneable tosetthedefaultpagesize
David S. Miller wrote: The only thing that breaks is if apps don't call sysconf(_SC_PAGESIZE) or some similar function such as getpagesize() to obtain that information portably. .. or they make assumptions about the possible range of values. ;) Or did Solaris accidently return 8K always in some version of the Solaris libc? I don't see how this is possible, as applications No that wasn't the case. The case Bart mentioned was one, an app was creating a unmapped zone around a segment and the segment ended up all being unmapped because they were subtracting 64K off of each end of a 128K segment. It was clearly a bug but since the app was statically linked to library code containing the bug there wasn't a good way to fix it in the field. There were the other drawbacks I mentioned as well, which we could get around by only upping the pagesize on newer platforms with better cache associativity and larger memory. This approach may be tenable. I also disagree with Eric Lowe about the usefulness of increasing the base page size. It's very useful, and that's why we have several platforms under Linux which have moved up to a default page size of 64K or larger (IA64, PowerPC 64-bit). We even use 256MB TLB entries for the Linux kernel on Niagara, and if the chip supported 16GB TLB entries we'd use those too, it's a huge issue. In the case of Niagara the tradeoffs are clearly in favor of optimizing for the TLB. Our auto-MPSS policies are very aggressive on that platform and result in most of the heap and stack mapped with 64K and larger pages, up to 256M, and large pages are also automatically selected for suitably sized text on that platform. It would be interesting to try native 64K PAGESIZE support on a Niagara and see how much of a win it is over what is currently available in Nevada... When the 64K prototype was done a few years back, most of the performance analysis was done on machines of the SunFire 6800-15K class since they have the biggest memories; Comparing SF68k/SF15k with Niagara is problematic. The broken MMU design in the US3/4 CPU models used in these machines is not able to use a significant amount of 64k pages. If you still got a small performance win there then this would prove that an all-64k kernel has significant performance advanges over the stock version with it's 8k dwarf page size. this was before Niagara silicon even taped out! Could Sun get the project code released into Opensolaris, please? I agree with both David Miller and Roland Mainz that a kernel which uses 64k pages by default will have significant performance advantages over the kernel which uses dwarfpages. The 8k page size is a significant limitation. Holger This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: RFE: /etc/system tuneable to setthedefaultpagesize
On Wed, Mar 08, 2006 at 02:14:25AM +0100, Roland Mainz wrote: BTW: The discussion was about a _tuneable_ which could be set to a value used as default page size (used by kernel and returned by |getpagesize()|co.) - the default for this tuneable should remain 8k. It would allow people to switch to 64k pages on demand and even allows them to return to the 8k size if something breaks (e.g. setting the tunable is not mandatory). Additionally a shared library similar to /usr/lib/[EMAIL PROTECTED] could be provided to switch to the old page size if individual userland applications cause trouble. And there would be a way to fix all those broken applications out there. Without having such a tuneable it is almost impossible to fix the applications which makes the situation even worse (which may backfire at some point in the future). The problem here is that you lose most of the benefits in the kernel if the size is tunable, in one of two directions: either you still have 8k pages in the kernel (i.e. . you have 4x the number of page_ts than you need, and you're e *always* dealing with large pages), or I do not see a problem here. The kernel will only offer 64k, 512k and 4M pages (on US1/2/T1). 8k pages will be not available. This eliminates all need for emulation. Holger This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: RFE: /etc/system tuneable to setthedefaultpagesize
On 3/9/06, Dave Marquardt [EMAIL PROTECTED] wrote: Holger == Holger Berger [EMAIL PROTECTED] writes: The problem here is that you lose most of the benefits in the kernel if the size is tunable, in one of two directions: either you still have 8k pages in the kernel (i.e. . you have 4x the number of page_ts than you need, and you're e *always* dealing with large pages), or Holger I do not see a problem here. The kernel will only offer 64k, Holger 512k and 4M pages (on US1/2/T1). 8k pages will be not Holger available. This eliminates all need for emulation. Minor nit: 512k pages aren't available on Niagara (T1). OK. 64k, 4M and 256M pages on T1 then. Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: RFE: /etc/system tuneable to set the defaultpagesize
To make matters worse, Solaris (unlike many other OS's) ties page_t structures to particular physical addresses, and there is plenty of code that assumes p_pagenum can't change even if the page isn't locked. This complicates the issues of separating out the page size the user sees and the page size the kernel is using to manage physical memory. I assume this is no problem when the default page size is equal to the minimum page size supported by the kernel. A kernel which only supports 64k+ page sizes will avoid page_t related headaches . Holger This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
