[osol-discuss] Re: [sfwnv-discuss] Web Stack NG Project: Questions for the Community
On Wed, Mar 21, 2007 at 12:28:59PM -0400, Stefan Teleman wrote: > Hi. > > The ARC Cases for the WebStack NG Project have been submitted for review > (and hopefully approval), and i would like to ask our community's input > regarding two important questions which have come up during our discussions: > > 1. Should the initial components released for this project include the > 64-bit bits in the initial Integration ? If it delays the release then no. > 2. The currently proposed Apache 2.2.4 integration installs Apache in > /usr/apache2, thereby _overwriting_ the existing Apache 2.0.x. Valid > arguments have been made pro, and against this approach, with the > suggestion that Apache 2.2.4 installs in /usr/apache2.2, thereby preserving > the existing /usr/apache2. However, this alternate location would *not* > alter the EOF/EOL timeout announced for Apache 2.0.x. Whatever proposal wins it should preserve _choice_ for admins/developers. Let _them_ decide which version they are going to use. If we are going to compete with linux we should give choice because one of linux strength is giving choice (one may disagree with me but I have written "one of"). After all the configuration (and the choice !) is for them: admins/developers. Regards przemol -- Jestes kierowca? To poczytaj! >>> http://link.interia.pl/f199e ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Web Stack NG Project: Questions for the Community
On Thursday 22 March 2007 12:57 am, Bob Palowoda wrote: > You might have to have sym links for /etc/apache and /var/apache also. > The runtime environment is controlled by apache APR utilities. This is about the time zones start lookin' good...in fact, that should be the reccomended way to run PHP, in a zone that's been locked down solid. AMPZ - hardened zone for running PHP AMPZZ - High voltage, runing at zettaHZ (i.e., zfs;-) -- Alan DuBoff - Solaris x86 Engineering - IHV/OEM Group Advocate of insourcing at Sun - hire people that care about our company! ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Traditional Chinese locale bug (was: Re: Video Problem in SX59)
Hi Ienup (& Jack): I knew that once you saw those three simple words (& they are in plain English), you would instantly recognize the potential calamity--and the uproar--that they may cause. I am also sure you will now sympathize why I have been so allusive about this matter, This thing (not just a bug) is so repugnant that no one dares to be its messenger. There should be no doubt that Solaris Express will not be allowed in Taiwan so long as these three simple words are not removed. This is the best case scenario. We are all willing to believe that this is just an unfortunate mistake caused by ignorance and a total lack of political sensitivity. However, to those who may intimately feel offended, Sun will not be so easy getting off the hook. And the trashing can drag on for an unbearable duration, especially when the current Taiwan government is going through its own version of the Cultural Revolution (see the March 17th issue of the Economist) and is eager to find a target enemy. Ienup Sung wrote: > Thanks very much... > > Hi Wayne, > > Thanks very much once again for bring this issue to the forum. Much > appreciated. I think this is just a mistake caused by ignorance and > this appears a P1 top bug that need to fixed as soon as possible for > the next build. > > Ienup > > Jack Kang wrote at 03/21/07 19:40: >> We haven't provided any translation for new dtlogin language selection >> panel. it is an English issue. we will file a bug against this issue. CDE >> team will handle it. >> >> thanks, >> >> jack >> >> Ienup Sung wrote: >> >>> [ I changed Alan's email address and opensolaris-discuss to Bcc at this >>> reply. Please check on or join i18n-discuss if you're interested in this >>> discussion. ] >>> >>> Thanks, Alan, for bring this to i18n-discuss. >>> >>> Hello Wayne, >>> >>> Thanks for bring up on the "derogatory" language issue. >>> >>> Would you please remind this forum on the derogatory language associated >>> with >>> the Traditional Chinese locale at Build 56? >>> >>> If you have already sent in, sorry, somehow I don't remember email thread at >>> this forum mentioning about the issue and wondering if I missed it... >>> >>> Thanks very much in advance, >>> >>> Ienup >>> >>> Alan Coopersmith wrote at 03/21/07 09:39: >>> > Now back to my main issue. The "derogatory" language associated with the > traditional Chinese locale has not been corrected. I went back to Build > 55b, & it was OK there. Apparently someone sneaked in this change in > Build 56. As it stands now, Solaris Express will be banned in Taiwan (& > Sun will be publicly persecuted if someone makes a big deal out of it). > I am sure this is an inadvertent error. [EMAIL PROTECTED] (which I've cc'ed here) is the most efficient way to get the attention of the people responsible for those translations, but without more detail about what you find objectionable (i.e. what wording on what screen/application) I'm not sure what they can do. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: [sfwnv-discuss] Web Stack NG Project: Questions for the Community
On Thu, Mar 22, 2007 at 09:18:07AM +0100, [EMAIL PROTECTED] wrote: > > > 2. The currently proposed Apache 2.2.4 integration installs Apache in > > /usr/apache2, thereby _overwriting_ the existing Apache 2.0.x. Valid > > arguments have been made pro, and against this approach, with the > > suggestion that Apache 2.2.4 installs in /usr/apache2.2, thereby preserving > > the existing /usr/apache2. However, this alternate location would *not* > > alter the EOF/EOL timeout announced for Apache 2.0.x. > > Whatever proposal wins it should preserve _choice_ for admins/developers. > Let _them_ decide which version they are going to use. > If we are going to compete with linux we should give choice because > one of linux strength is giving choice (one may disagree with me but I > have written "one of"). > > After all the configuration (and the choice !) is for them: admins/developers. To add something: it is not difficult to imagine situation when production environment is using apache 2.0 and testing/development environment moved to apache 2.2 (still on the same physical server - especially using zones). IMHO capability of using both concurrently is the most convenient and may atract much more admins and developers. Regards przemol -- Jestes kierowca? To poczytaj! >>> http://link.interia.pl/f199e ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Update Manager Freezes
well I got a few other responses from other people on this forum. According to them it won't work since Update Manager works only with Sun Solaris (not OpenSolaris Nevada) the reason why it won't work is that "Solaris Express, Community Edition is Sun's binary release for OpenSolaris developers (code named "Nevada"). It is built from the latest OpenSolaris source and additional technology that has not been published in the OpenSolaris source base. This release is unsupported. Developers can build the OpenSolaris source by using this release as the base system. It is updated every other Friday." P.S> If you want to have updatemanager working you need to install Sun Solaris and not OpenSolaris. For Sun Solaris go to Sun.com This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Single Systema Image with OpenSolaris
Hi Gustavo, I am not sure if I understand your question completely. There is an application on openSolaris called Sun Cluster which itself is multithreaded and is able to migrate any threaded program from nodes to nodes in failover configuration. It is available for free download on http://www.sun.com/software/solaris/cluster/get.html All you need to do is to create a Sun Cluster agent for your application using using "Sun Cluster Agent Builder" and deploy it. There you go.. Regards, _Atul On 3/20/07, Gustavo Enrique Jimenez <[EMAIL PROTECTED]> wrote: Hi all It is possible to build a Single System Image with OpenSolaris ? In that case, it is possible to write a program using threads that migrates every threads to another nodes ? I am a linux programmer, and Linux does't have "green threads". So, threads doesn't migrates to the nodes. You have to write forked programs to migrate childs to ohter nodes, and the inter process comunication gets messy. Sorry for my bad english. I am very interested in OpenSolaris, and if I could write threaded programs to do cluster programming, well, that would be great ! Excuse my english, and thanks for your time. Gustavo ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Beryl ?
Is there a beryl + emerald pkg for OpenSolaris 10 ? This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Beryl ?
Hi Horvath, There is no packages yet but you can find details on how to compile Beryl here : http://www.opensolaris.org/jive/thread.jspa?messageID=100776𘦨 If you're interested in compiz you can find details on how to compile it here : http://www.opensolaris.org/jive/thread.jspa?messageID=98580𘄔 and http://www.opensolaris.org/jive/thread.jspa?messageID=99586𘔂 HTH, Erwann Horvath wrote: Is there a beryl + emerald pkg for OpenSolaris 10 ? This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- Erwann Chénedé, Desktop Group, Sun Microsystems, Grenoble [ I speak for myself, not for my employer ] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] joining Sun
On 3/21/07, Ian Murdock <[EMAIL PROTECTED]> wrote: There are some interesting connections to Linux here as well. If you think about it, what do people want when they say they want "Linux"? The Linux kernel? Or the Linux distribution (i.e., GNU)? Could Solaris become a "better Linux than Linux" by following that line of thinking? And if you following that line of thinking, where does that lead the company in terms of Linux strategy? Some interesting parallels open up with the way Sun masterfully embraced x86 a few years ago... As a Linux user who has recently started working with the OpenSolaris kernel for a project, I have been thinking about this as well. What I personally find important in Linux is: - the user experience, mostly embodied by the KDE desktop environment. I don't like Gnome, so I don't like the default Solaris desktop environment. I heard that there is a KDE project for OpenSolaris, so that is great. If most of the GUI programs would run on OpenSolaris as well, then the biggest challenge has been overwon I think. - then there are the command line programs. There might be a good reason for this, but I feel that some of the Solaris-shipped tools are inferior to the GNU tools. For example, I don't see a reason why a simple recursive grep with 'grep -R' does not work on Solaris. Why there are two greps is something I do not understand either. I do not get the way man works either. On Linux, you would just do "man cat" or "man vi", and it would just give you the correct man page. Even 'man man' doesn't work here. (I'm beginning to wonder whether this may be because the man pages are not installed... could this be? man man should work, right?) I agree that a lot of this frustration is more because it is unknown and different than what I am used to. But I think this will be the case for a lot of users which come from Linux, and if Solaris wants to make these people change OS, this should be taken into account. - the actual kernel is not very important from a user point of view I think. What is important is the hardware support, and I am not sure to what extent OpenSolaris is good at this. For example, I have an Acer laptop with an embedded webcam. For Linux, there was reasonably quickly a driver (gspca) available. I don't know if this would have been the case with OpenSolaris. Of course, this also depends on the size of the developer community and I think that's were Linux has a plus. As a developer, the kernel code of OpenSolaris seems much more documented and organised than that of Linux, which is definitely a plus. If OpenSolaris can get these three points right, I believe it could be a great alternative... ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: blastwave package handling [was Re: Re: joining Sun]
Jason Ozolins writes: > > Jason Ozolins writes: > > packages). This kind of explains why Sun puts out > > _patches_ rather than new versions of packages - > > because applying the latter can't be done easily to a > > running OS instance. SVR4 package management just > > wasn't designed to work the way that people expect > > package management to work these days. > > > > Not true on both counts. > > What are the two counts? My supposed misunderstanding of patches vs > packages is one, but I'm not sure which of my other statements is supposed to > be bogus. It doesn't explain why we use patches, and the existence of a running instance doesn't have much to do with it. Internally, patches use what are called "sparse" packages. If you look inside a patch, you'll see bunch of somewhat ordinary-looking packages. What's special about them is that they contain only *some* of the files that were in the original package -- specifically, the files that changed. The system relies on the fact that it can overwrite the package and only those files will be touched. > > necessary. Blastwave could do this with > > "instance=overwrite," and > > probably should, but it doesn't. > > Umm, I think we're writing at cross purposes here... Indeed. > Remove package, shared libs, That's not correct. It's possible to use the admin(4) file to get a different behavior out of pkgadd. > kill daemon for duration of upgrade, [probably killing running telnet > sessions in the process] That *may* be necessary, but it has essentially nothing to do with whether you're using a package or a patch. The key issues are not related to the delivery mechanism, but rather due to aspects of what's being delivered. The packaging system (which is used by patching under the covers) always writes to a new file and then moves the object into place. This means that it's actually safe to do an overwrite-install of a package while the object is running, provided that: - the object already has all the files (including shared libraries) open that it's going to need, and isn't going to lazy-load or dlopen after you've started the upgrade process. - any other changes made to the system as a part of the package install process (such as rewriting configuration files) are not of a nature that will "confuse" this running process. It's in enumerating those issues, and following the logical chains through other libraries and options, that the complexity arises. This is why many patches from Sun recommend single-user (to make sure that nothing's running, as we can't guarantee the consistency above) and quite a few say "reboot immediate." Blastwave's approach has essentially the same underlying issues, even if the user experience is different. > reinstall package, maybe cream config files somewhere in the process. As for configuration files that get removed or damaged in the upgrade process, that's an upstream packaging error. The package creator has to be aware of how the upgrade will take place, and plan for it so that the necessary information isn't nuked in the process. Inside Sun, we handle this problem through a variety of review and testing procedures (the ARC is part of this, but there are many other parts). I'm not sure how blastwave handles review of packaging rules and upgrade planning -- that's something you should take up with them (and probably not on this list). The same is actually true for patches. > complain. But my original post was just trying to point out that > the existence of Blastwave and Sunfreeware is not enough for Solaris > to win mindshare among folks who have used Linux distros with decent > package management, an example being my co-workers and management. > If I failed to understand some nuanced differences between Solaris > patches and packages, it really doesn't detract from that point. I strongly agree with that. The quality of the upgrade experience has an enormous impact on whether a platform is viable at all in a production environment. I don't think, though, that "decent package management" is entirely or even primarily a feature of the packaging software itself. A huge amount of the effort rests on the project teams who package and deliver the software -- if they don't think through the upgrade scenarios clearly, there's not much that even the most sophisticated packaging tools can do to save them. Good tools can help, but there's no magic bullet here. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] joining Sun
Another thing that came to mind: the fact that Solaris needs a primary partition to install on is a big problem in my view. I had set-up my disk so there were 3 logical partitions of about 15GB for operating systems (linux and I hoped OpenSolaris as well). Obviously, Solaris couldn't install and I am not keen on repartitioning my whole disk. Adding a new disk isn't a real option either since this is a laptop. Probably there is a good reason for this partition way, but IF this could change, it would definitely lower the barrier from Linux I think. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] joining Sun
yes, I'm also a long time Linux user/developer who has recently working on Solaris for a research project base on the DTrace tool. It's true there're plenty of powerful tools in Solaris, but some habitual Linux tools are miss or different. And this makes me feel uncomfortable. Baseing on Solaris kernel's excellent performance and adding Linux tools on it, it is a good way to popularize the Solaris. I think the combination is very important if Sun wants to scramble for the desktop users and the Linux developers. 2007/3/22, Thomas De Schampheleire <[EMAIL PROTECTED]>: On 3/21/07, Ian Murdock <[EMAIL PROTECTED]> wrote: > > There are some interesting connections to Linux here as well. If you > think about it, what do people want when they say they want "Linux"? > The Linux kernel? Or the Linux distribution (i.e., GNU)? Could Solaris > become a "better Linux than Linux" by following that line of thinking? > And if you following that line of thinking, where does that lead the > company in terms of Linux strategy? Some interesting parallels > open up with the way Sun masterfully embraced x86 a few years ago... As a Linux user who has recently started working with the OpenSolaris kernel for a project, I have been thinking about this as well. What I personally find important in Linux is: - the user experience, mostly embodied by the KDE desktop environment. I don't like Gnome, so I don't like the default Solaris desktop environment. I heard that there is a KDE project for OpenSolaris, so that is great. If most of the GUI programs would run on OpenSolaris as well, then the biggest challenge has been overwon I think. - then there are the command line programs. There might be a good reason for this, but I feel that some of the Solaris-shipped tools are inferior to the GNU tools. For example, I don't see a reason why a simple recursive grep with 'grep -R' does not work on Solaris. Why there are two greps is something I do not understand either. I do not get the way man works either. On Linux, you would just do "man cat" or "man vi", and it would just give you the correct man page. Even 'man man' doesn't work here. (I'm beginning to wonder whether this may be because the man pages are not installed... could this be? man man should work, right?) I agree that a lot of this frustration is more because it is unknown and different than what I am used to. But I think this will be the case for a lot of users which come from Linux, and if Solaris wants to make these people change OS, this should be taken into account. - the actual kernel is not very important from a user point of view I think. What is important is the hardware support, and I am not sure to what extent OpenSolaris is good at this. For example, I have an Acer laptop with an embedded webcam. For Linux, there was reasonably quickly a driver (gspca) available. I don't know if this would have been the case with OpenSolaris. Of course, this also depends on the size of the developer community and I think that's were Linux has a plus. As a developer, the kernel code of OpenSolaris seems much more documented and organised than that of Linux, which is definitely a plus. If OpenSolaris can get these three points right, I believe it could be a great alternative... ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] What is OpenSolaris success?
Mike Kupfer <[EMAIL PROTECTED]> wrote: > > "Jörg" == Joerg Schilling <[EMAIL PROTECTED]> writes: > > Jörg> Well, I did send the list to opensolaris-discuss and to Mike > Jörg> Kupfer (don't know his Borg name;-) on November 14th 2005. > > *Bzzz* *whrrr* How do you pronounce this? > Resistance is voltage over current! > Knowledge is power! > The air speed of a laden swallow is... uh... I don't knowUGH! > > :-D > > You're referring to > > > http://mail.opensolaris.org/pipermail/opensolaris-discuss/2005-November/011120.html > > right? Correct. 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 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Election Voting Opens Mon Mar 12th (00:00 hrs)
For the sake of clarity : Election Voting Opens Mon Mar 12th (00:00 hrs) Election Voting Closes Mon Mar 26th (24:00 hrs) Which is why I had cast my votes on Monday the 12th of March because the actual character of a person is far more important to me than anything they may say here or there or post in some response. I already have a good feel for who is running and who they are over the years that I have known them. I vote based on the person, their history and their true character in as much as I can fathom over the years. My reasons for not participating in the interview process are my own. I would have enjoyed a debate but I think that the debate process would have required too many rounds with too many judges and too much infrastructure to be practical. Having said all that .. I have one last thing to say and it will be my last word on matters before the voting process closes. I have been involved with the Solaris Community for quite some time. Over the past decade I have spoken with, worked with, played and argued with some really brilliant and vibrant personalities. People that either really *knew* what they were talking about or had a gift for helping other people. On rare occasion I was able to talk with people that could do both at the same time. Often times that is what "community" really means. The gathering together of our collective knowledge and personalities such that we may work together, play together and help each other. I am overwhelmed by the number of times that I have worked well through the night on some problem and had a number of people "right there" watching and helping and getting involved. Last night was a great example for those that helped and you know who you are. :-) There have been times when I have stayed on the phone/keyboard/whatever all night helping someone else. This is what *we* do. Some of us are getting paid to do these things and some are in there with their guts and hearts and nothing else. There are a number of us here that have been around as long as I can recall. I know that the internet puts us all at a distance while also bringing us together. Its a whole new world of relationships that work within a dynamic we are still only beginning to really understand as the social creatures that we are. Sometimes just watching green letters pop up on an xterm are all that we know of each other. Sometimes we live next door or around the corner. Have I ever met you? What do we mean by "meet" in this new world? In this new paradign for human relationships we are often misunderstood because we are social creatures and not really "built" for such disconnected relations. Somehow we have to keep working forwards while our technology finds ways to bring us together. I think that is what I am doing .. working to bring us, the community, forwards. Dennis Clarke ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] joining Sun
On 22/03/07, Thomas De Schampheleire <[EMAIL PROTECTED]> wrote: - then there are the command line programs. There might be a good reason for this, but I feel that some of the Solaris-shipped tools are inferior to the GNU tools. For example, I don't see a reason why a simple recursive grep with 'grep -R' does not work on Solaris. It doesn't on linux either (i think you mean 'grep -r'), but yes - this drives me mad too :) You should have a /usr/sfw/bin/ggrep that works how you want - if not, you need to add the 'SUNWggrp' package. Even 'man man' doesn't work here. (I'm beginning to wonder whether this may be because the man pages are not installed... could this be? man man should work, right?) Either the man command or the manpages aren't installed on your box: pkgadd -d /cdrom/Solaris_11/Product SUNWdoc SUNWman catman -w - the actual kernel is not very important from a user point of view I think. What is important is the hardware support A few years back you'd just check hardware worked with Linux before buying it. If you're going to build a dedicated Solaris box, that's the best plan (although the hardware compatibility list for sun needs some TLC). -- Rasputin :: Jack of All Trades - Master of Nuns http://number9.hellooperator.net/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to include dirfd(3C) into OpenSolaris
Jonathan Wheeler <[EMAIL PROTECTED]> wrote: > Hi All, > > Though I don't personally have enough knowledge about the subject to really > make a very good argument here, it's been suggested by steleman (from > #opensolaris), that I start a thread on OpenSolaris-discuss about this > function, and the possibility of including it within upcoming builds > Opensolaris. > > Starting all this was my attempt to compile the latest > official build of Amarok under Solaris. As of version 1.4.5 they've started > using dirfd(3C), which Solaris doesn't have - resulting in G++ bailing out. Solaris has fdopendir() which is more important as it allows you to call: fd = openat(ofd, path, O_READ); dir = fdopendir(fd); in order to remove the PATH_MAX limitation. But BTW: dirfd() would be just: #define dirfd(dp) (dp)->dd_fd 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 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: blastwave package handling
[Convention-aware me: "I'm sorry here for following up to my own post." Actual Me: "Why should I be?"] Previously, I wrote: Previously, Dave Miner wrote: At the risk of repeating myself for about the 50th time in the past year, I'd encourage these packaging-related discussions to occur with the community list specifically devoted to them, [EMAIL PROTECTED] Those in the community with ideas can actually start working on them, since the packaging sources are open, and have been for over a year now. An interesting metric would be the percentage of core contributors who (understandably IMO) don't read this list. Sorry, major context error. What I meant to say was all opensolaris core contributors (not just those of the install community). Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] joining Sun
On 3/22/07, Dick Davies <[EMAIL PROTECTED]> wrote: It doesn't on linux either (i think you mean 'grep -r'), but yes - this drives me mad too :) You should have a /usr/sfw/bin/ggrep that works how you want - if not, you need to add the 'SUNWggrp' package. In my version of grep (2.5.1), -R and -r are the same. I use -R because a lot of other tools, like ls, only support -R. ls -r means 'reverse'. Another annoyance is that most tools do not accept --help. This is common with GNU tools, and I prefer it over -h, because some tools might use -h for a real thing. In case -h means "remove all files", then you're screwed... > Even 'man man' doesn't work here. (I'm beginning to wonder > whether this may be because the man pages are not installed... could > this be? man man should work, right?) Either the man command or the manpages aren't installed on your box: pkgadd -d /cdrom/Solaris_11/Product SUNWdoc SUNWman catman -w pkginfo SUNWman does show: system SUNWman On-Line Manual Pages doesn't this mean it is installed? ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to include dirfd(3C) into OpenSolaris
On Thursday 22 March 2007 10:21, Joerg Schilling wrote: > But BTW: dirfd() would be just: > > #define dirfd(dp) (dp)->dd_fd This works really well when (dp) is NULL. --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to include dirfd(3C) into OpenSolaris
Stefan Teleman <[EMAIL PROTECTED]> wrote: > On Thursday 22 March 2007 10:21, Joerg Schilling wrote: > > > But BTW: dirfd() would be just: > > > > #define dirfd(dp) (dp)->dd_fd > > This works really well when (dp) is NULL. ??? Garbage in -> garbage out. Do not expect to get useful results in case that you use useless input. 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 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to include dirfd(3C) into OpenSolaris
On Thu, 22 Mar 2007, Stefan Teleman wrote: On Thursday 22 March 2007 10:21, Joerg Schilling wrote: But BTW: dirfd() would be just: #define dirfd(dp) (dp)->dd_fd This works really well when (dp) is NULL. --Stefan Found those: http://www.die.net/doc/linux/man/man3/dirfd.3.html http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/dirfd.3.html\ http://www.freebsd.org/cgi/man.cgi?query=dirfd None of them mentions whether DIR can be NULL. One could argue 'returns -1 on error' would mean they should return -1 then - but then, neither of the above specify what errno would have to be set to. Strictly conformant to the above would therefore be: #define dirfd(dp) ((dp) ? (dp)->dd_fd : -1) You'd still crash if you pass an invalid pointer, though. I don't see why people always expect to be protected against NULL pointers but accept that 'random' pointers still cause issues. See the printf() discussion from a few months ago ... FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to include dirfd(3C) into OpenSolaris
On Thursday 22 March 2007 12:29, Joerg Schilling wrote:
> Stefan Teleman <[EMAIL PROTECTED]> wrote:
> > On Thursday 22 March 2007 10:21, Joerg Schilling wrote:
> > > But BTW: dirfd() would be just:
> > >
> > > #define dirfd(dp) (dp)->dd_fd
> >
> > This works really well when (dp) is NULL.
>
> ???
>
> Garbage in -> garbage out.
>
> Do not expect to get useful results in case that you
> use useless input.
/* testnulldir.c */
#include
#include
#include
#define dirfd(dp)(dp)->dd_fd
static const char* dirname = "/this/baby/does/not/exist";
int
main(int argc, char* argv[])
{
DIR* dir;
int fd;
fd = dirfd(opendir(dirname));
(void) fprintf(stderr, "dirname fd = %ld\n", fd);
return 0;
}
[EMAIL PROTECTED]/tmp][03/22/2007 12:26:45][242]>> echo $CFLAGS
-Xc -erroff=%all -errshort=full -errfmt=error -errwarn=%none -xO3 -s -xjobs=2
-xregs=no%frameptr -dalign -xprefetch=auto
-xprefetch_auto_type=indirect_array_access -xprefetch_level=3 -xbuiltin=%all
-xcsi -xinline=%auto -xustr=ascii_utf16_ushort -z
combreloc -z redlocsym -z nodefaultlib -z now -z rescan -z
absexec -xipo=0 -xildoff -xldscope=symbolic -xrestrict=%all -xF=%none
-xalias_level=std -xsafe=mem -xthreadvar -lc -lpthread -lposix4 -lrt -mt
-D_REENTRANT -D__EXTENSIONS__=1 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_XPG4 -D_XPG4_2 -D_XPG6 -D_POSIX_PTHREAD_SEMANTICS -D_XOPEN_SOURCE=600
-D_POSIX_C_SOURCE=200112L -D__XOPEN_OR_POSIX -D_STRICT_STDC -D_STRICT_STDC__
-D_STDC_C99 -DAPR_BUCKET_DEBUG=1 -DAPR_RING_DEBUG=1 -DAPR_POOL_DEBUG=0
-DSOLARIS -DSOLARIS10 -DSOLARIS2=10 -DUSE_SOLARIS -DNDEBUG -DNO_DEBUG -KPIC
-xtarget=pentium4 -xarch=sse2 -xchip=pentium4 -xcache=8/64/4:256/128/8 -xO3 -s
[EMAIL PROTECTED]/tmp][03/22/2007 12:26:47][243]>>
[EMAIL PROTECTED]/tmp][03/22/2007 12:26:47][243]>> $CC $CFLAGS
$LDFLAGS testnulldir.c -o testnulldir
"testnulldir.c", line 14: error: undefined struct/union member: dd_fd
c99: acomp failed for testnulldir.c
[EMAIL PROTECTED]/tmp][03/22/2007 12:27:23][244]>>
we now change
#define dirfd(dp)(dp)->dd_fd
to
#define dirfd(dp)(dp)->d_fd
[EMAIL PROTECTED]/tmp][03/22/2007 12:28:10][246]>> $CC $CFLAGS
$LDFLAGS testnulldir.c -o testnulldir
[EMAIL PROTECTED]/tmp][03/22/2007 12:28:12][247]>> ./testnulldir
Segmentation fault (core dumped)
[EMAIL PROTECTED]/tmp][03/22/2007 12:28:17][248]>>
--Stefan
--
Stefan Teleman 'Nobody Expects the Spanish Inquisition'
KDE e.V.-Monty Python
[EMAIL PROTECTED]
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to include dirfd(3C) into OpenSolaris
Frank Hofmann <[EMAIL PROTECTED]> wrote: > On Thu, 22 Mar 2007, Stefan Teleman wrote: > > > On Thursday 22 March 2007 10:21, Joerg Schilling wrote: > > > >> But BTW: dirfd() would be just: > >> > >> #define dirfd(dp) (dp)->dd_fd > > > > This works really well when (dp) is NULL. > > > > --Stefan > > Found those: > > http://www.die.net/doc/linux/man/man3/dirfd.3.html > http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/dirfd.3.html\ > http://www.freebsd.org/cgi/man.cgi?query=dirfd > > None of them mentions whether DIR can be NULL. Many other FILE * functions crash in case that you pass them a NULL pointer. 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 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to include dirfd(3C) into OpenSolaris
Stefan Teleman <[EMAIL PROTECTED]> wrote:
> /* testnulldir.c */
>
> #include
> #include
> #include
>
> #define dirfd(dp)(dp)->dd_fd
> static const char* dirname = "/this/baby/does/not/exist";
>
> int
> main(int argc, char* argv[])
> {
> DIR* dir;
> int fd;
>
> fd = dirfd(opendir(dirname));
> (void) fprintf(stderr, "dirname fd = %ld\n", fd);
> return 0;
> }
This is a non-conforming program as it uses the return value of opendir()
in case of an error.
> [EMAIL PROTECTED]/tmp][03/22/2007 12:26:45][242]>> echo $CFLAGS
> -Xc -erroff=%all -errshort=full -errfmt=error -errwarn=%none -xO3 -s -xjobs=2
> -xregs=no%frameptr -dalign -xprefetch=auto
> -xprefetch_auto_type=indirect_array_access -xprefetch_level=3 -xbuiltin=%all
> -xcsi -xinline=%auto -xustr=ascii_utf16_ushort -z
> combreloc -z redlocsym -z nodefaultlib -z now -z rescan -z
> absexec -xipo=0 -xildoff -xldscope=symbolic -xrestrict=%all -xF=%none
> -xalias_level=std -xsafe=mem -xthreadvar -lc -lpthread -lposix4 -lrt -mt
> -D_REENTRANT -D__EXTENSIONS__=1 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> -D_XPG4 -D_XPG4_2 -D_XPG6 -D_POSIX_PTHREAD_SEMANTICS -D_XOPEN_SOURCE=600
> -D_POSIX_C_SOURCE=200112L -D__XOPEN_OR_POSIX -D_STRICT_STDC -D_STRICT_STDC__
> -D_STDC_C99 -DAPR_BUCKET_DEBUG=1 -DAPR_RING_DEBUG=1 -DAPR_POOL_DEBUG=0
> -DSOLARIS -DSOLARIS10 -DSOLARIS2=10 -DUSE_SOLARIS -DNDEBUG -DNO_DEBUG -KPIC
> -xtarget=pentium4 -xarch=sse2 -xchip=pentium4 -xcache=8/64/4:256/128/8 -xO3 -s
> [EMAIL PROTECTED]/tmp][03/22/2007 12:26:47][243]>>
>
> [EMAIL PROTECTED]/tmp][03/22/2007 12:26:47][243]>> $CC $CFLAGS
> $LDFLAGS testnulldir.c -o testnulldir
> "testnulldir.c", line 14: error: undefined struct/union member: dd_fd
> c99: acomp failed for testnulldir.c
> [EMAIL PROTECTED]/tmp][03/22/2007 12:27:23][244]>>
Well, if you use additional options/Defines, you would need to know how
to handle the effetcs.
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
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to include dirfd(3C) into OpenSolaris
Stefan Teleman writes: > On Thursday 22 March 2007 10:21, Joerg Schilling wrote: > > > But BTW: dirfd() would be just: > > > > #define dirfd(dp) (dp)->dd_fd > > This works really well when (dp) is NULL. Ignoring the NULL question for a moment, think it would be quite wrong to implement this as a #define. We should have learned our lesson with the fileno() #define that caused a couple of decades of FILE * 255-limit ABI carnage. I don't believe that the 'DIR' structure members are publicly documented, so we shouldn't be using macros to bake the offsets of any of the members into applications. On the NULL question, I prefer to see a core dump. There's nothing particularly special about NULL when considered as one of the possible invalid pointers that could be passed in. If we were to guard against invalid pointers, then we would need to record the results of opendir() and closedir() and make sure that only the known live pointers are used -- and I think that's absurdly ambitious. Guarding against NULL alone but still allowing other bogus pointers to crash the application seems to me to have little value. Perhaps more importantly, any application that's errantly dealing in NULL pointers needs to crash as soon as possible, rather than drive on to corrupt user data. That core dump is for the greater good of society. ;-} -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] joining Sun
>In my version of grep (2.5.1), -R and -r are the same. I use -R >because a lot of other tools, like ls, only support -R. ls -r means >'reverse'. Tools like "grep" really should not have sprouted a "-R" because it is contrary to the Unix tool philosophy. Gnu apparently wants to reimplement all tools inside all other tools. >Another annoyance is that most tools do not accept --help. This is >common with GNU tools, and I prefer it over -h, because some tools >might use -h for a real thing. In case -h means "remove all files", >then you're screwed... All our tools accept "man tool"; that's actually 3 letters less typing. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Overview (rollup) of recent activity on opensolaris-discuss
For background on what this is, see: http://www.opensolaris.org/jive/message.jspa?messageID=24416#24416 http://www.opensolaris.org/jive/message.jspa?messageID=25200#25200 = opensolaris-discuss 03/01 - 03/15 = Size of all threads during period: Thread size Topic --- - 55 Project proposal: User Mode Driver 40 Last Day for Nominations 38 About Solaris (mistakes) and future 31 What is OpenSolaris success? 27 Will "Solaris" be open-source in the future 16 Project Proposal: Mozilla DTrace project 14 which iso is for production server 12 SuperMicro 7045B/AHCI 12 OpenSolaris Conference in Germany 11 How do I know (with which command) the brand and model of my graphics card? 10 snv_59 not installable at all: 10 Three screencasts of OpenSolaris Technologies 10 Proposoal for a new OpenSolaris project: Kernel Sockets 10 OpenSolaris sessions at JavaOne 9 Revenge of the Unkillable Process 9 /vol/dev/aliases in NV 58 issue 8 Sun joins the Free Software Foundation 8 Belenix DVD 0.6 comments 7 Why should I vote for you? 7 Mess 7 Elluminate...possible solution? 7 netsnmp in /usr/sfw 6 Y2K7 update? 6 SUN_SSH and Solaris 8 6 Proposal for a new OpenSolaris project: Pluggable Sockets 6 Project Proposal: NFS Server in Local Zones 6 OGB Nomination 5 solaris 10 zone and /tmp 5 newbie: how to install and update apps in solaris 10 express commun 5 Project: Writing code for closed binaries 5 Project Proposal: NFSv4 namespace extensions 5 3 solaris problems 5 Project Proposal :: Google's Sumer of Code 4 smc hangs nevada 59 4 newbe: which solaris 10 iso file should be downloaded? 4 good intentions, wrong approach 4 dladm aggregate aggr1 mac address messages during bootup 4 constitutional limitations 4 Solaris Express b59 4 Solaris 10 Update testing 4 SXCE Build 59 available 4 Nominating ... 4 New Nvidia 1.0-9755 works with 64bit Xorg.7.2 on Build 59 4 It works when I choose the console install mode: 4 Intel Project going live 4 Hypervisor for SPARC T1 4 Four OS booting in GRUB 4 Errror in OpenSolaris Device Detection Tool 4 Build 59 dhcp client oddities 3 why is driver xy not distributed by opensolaris 3 post 3 opensolaris 10 express community support Sata drive? 3 obdiag errors on SunFire v880 3 newbie - kstat help please - bytes not updated for my NIC on an x86 3 Why libc.so.1 mounted? 3 Slow metadb and metastat on Build 55 3 SXCE Build 59 issue 3 Project Proposal: Next Generation Web Stack 3 Problem with a password change for an user 3 Moderator 3 Mapping Kerberos principal name to NFS Domain 3 Failure to install Solaris Express 12/06 on ASUS P5B Deluxe 3 Project proposal: java kstats 2 when was intel wireless support removed from nevada? 2 virtual interfaces in non-global zone ? 2 mq_open fails with errno EEXIST(17) 2 just for confirm about partition before installing solaris 10 2 Zone and NCA 2 Suggestion: PCFS Open Development Project 2 Solaris 8 VLAN interfaces 2 Project Proposal: Enable/Enhance Solaris support for Intel Platforms 2 Project Proposal: Enable/Enhance Solaris support for 2 Project Proposal: Country/Language Portals foropensolaris.org 2 OpenSolaris Developer Conference -- report from the orga team 2 Lost in NV_56-land. printing? Sendmail trying to contact Yahoo? HELP! 2 How to know least loaded cluster ? 2 Google Summer of Code :: Student Applications 2 Dtrace Question 2 Danke 2 Can Solaris Express Developer Edition be used to build OpenSolaris source? 1 opensolaris contribution 1 mplayer (blastwave) broken on snv 59 & 60 1 dladm aggregate aggr1 mac address messages during 1 Zones config 1 Xorg on SPARC (was: Last Day for Nominations) 1 XP Media Centre 1 Well, I would to become an OpenSolaris Contributor 1 Thunderbird 1.5.0.10 contrib. builds on Solaris10, Solaris8/9 are available 1 Sun Cluster Problem 1 Sun Cluster 1 Summer of Code project 1
Re: [osol-discuss] joining Sun
On 22/03/07, Thomas De Schampheleire <[EMAIL PROTECTED]> wrote: Another thing that came to mind: the fact that Solaris needs a primary partition to install on is a big problem in my view. I had set-up my disk so there were 3 logical partitions of about 15GB for operating systems (linux and I hoped OpenSolaris as well). Obviously, Solaris couldn't install and I am not keen on repartitioning my whole disk. Adding a new disk isn't a real option either since this is a laptop. I know the install "folks" are working with others to eventually support installing Solaris in an extended partition. In the meantime, a program like PartitionMagic, gparted, qtparted, etc. can help you re-arrange your partitions (non-destructively, though you should BACKUP YOUR DATA FIRST). This a known issue, but one that didn't matter so much in the past, since, as others pointed out, Solaris is used to being the only one on the drive. -- "Less is only more where more is no good." --Frank Lloyd Wright Shawn Walker, Software and Systems Analyst [EMAIL PROTECTED] - http://binarycrusader.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] joining Sun
On Thu, 22 Mar 2007, [EMAIL PROTECTED] wrote: > All our tools accept "man tool"; that's actually 3 letters less typing. Indeed; and for a concise "Usage" message, "tool -?" often (if not always) does the trick. -- Rich Teer, SCSA, SCNA, SCSECA, OpenSolaris CAB member CEO, My Online Home Inventory Voice: +1 (250) 979-1638 URLs: http://www.rite-group.com/rich http://www.myonlinehomeinventory.com ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] joining Sun
On 22/03/07, Thomas De Schampheleire <[EMAIL PROTECTED]> wrote: What I personally find important in Linux is: - the user experience, mostly embodied by the KDE desktop environment. I don't like Gnome, so I don't like the default Solaris desktop environment. I heard that there is a KDE project for OpenSolaris, so that is great. If most of the GUI programs would run on OpenSolaris as well, then the biggest challenge has been overwon I think. The challenge has been essentially met then, I believe. KDE was on Solaris a few years ago thanks to the stoic efforts of Stefan Teleman and others (see http://solaris.kde.org/). I would never expect sun to ship KDE in the main distribution though or as a default. On the "companion software" CD or something like that, sure... - then there are the command line programs. There might be a good reason for this, but I feel that some of the Solaris-shipped tools are inferior to the GNU tools. For example, I don't see a reason why a simple recursive grep with 'grep -R' does not work on Solaris. Why Because -R doesn't fit with the UNIX philosphy. It fits with the GNU philosophy. Remember, GNU stands for "GNU's NOT UNIX" :) there are two greps is something I do not understand either. I do not get the way man works either. On Linux, you would just do "man cat" or "man vi", and it would just give you the correct man page. Even 'man man' doesn't work here. (I'm beginning to wonder whether this may be because the man pages are not installed... could this be? man man should work, right?) Your manpath probably isn't set correctly. The default manpath for Solaris does *not* include all of the man directories for all installed software; it is up to you set it appropriately. Setting your manpath to include /usr/sfw/man, /opt/SUNWspro/man, etc. would probably alleviate most of these. As far as I know, Sun requires a man page for almost every binary, even if the software is 3rd party. -- "Less is only more where more is no good." --Frank Lloyd Wright Shawn Walker, Software and Systems Analyst [EMAIL PROTECTED] - http://binarycrusader.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] joining Sun
On 22/03/07, Thomas De Schampheleire <[EMAIL PROTECTED]> wrote: Another annoyance is that most tools do not accept --help. This is common with GNU tools, and I prefer it over -h, because some tools might use -h for a real thing. In case -h means "remove all files", then you're screwed... That is a matter of preference. I always hated the -- options GNU utilities use since they were so much more to type. I will admit GNU/Linux systems get you used to typing "cmd --help" instead of "man cmd" which I think is a bad habit. I think most people got used to doing this since documentation is something that was usually completely overlooked on most GNU/Linux distributions... -- "Less is only more where more is no good." --Frank Lloyd Wright Shawn Walker, Software and Systems Analyst [EMAIL PROTECTED] - http://binarycrusader.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] joining Sun
On Thu, 22 Mar 2007, Shawn Walker wrote: > That is a matter of preference. I always hated the -- options GNU > utilities use since they were so much more to type. I will admit You and me both! -- Rich Teer, SCSA, SCNA, SCSECA, OpenSolaris CAB member CEO, My Online Home Inventory Voice: +1 (250) 979-1638 URLs: http://www.rite-group.com/rich http://www.myonlinehomeinventory.com ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to include dirfd(3C) into OpenSolaris
>On Thursday 22 March 2007 10:21, Joerg Schilling wrote: > >> But BTW: dirfd() would be just: >> >> #define dirfd(dp)(dp)->dd_fd > >This works really well when (dp) is NULL. Yes, is will SEGV; is that an issue? getc(NULL) also blows up; what is your point? If you right buggy code without error checking it should blow up. But #define dirfd(dp) is wrong; it should be a function; we really do not want more macros which hardcode offsets for perpetuity. Remember fileno? Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to include dirfd(3C) into OpenSolaris
>None of them mentions whether DIR can be NULL. NULL is not a valid DIR * therefor you invoke undefined behaviour; then anything goes. >One could argue 'returns -1 on error' would mean they should return -1 >then - but then, neither of the above specify what errno would have to be >set to. No. >Strictly conformant to the above would therefore be: > >#definedirfd(dp) ((dp) ? (dp)->dd_fd : -1) No. Nothing to do with strictly conformant; while it is possible to have a DIR * which is NULL, using it immediately gets you undefined behaviour. IMHO, implementations MUST NOT protect against that; that way madness and buggy programs lie. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] joining Sun
>On Thu, 22 Mar 2007, [EMAIL PROTECTED] wrote: > >> All our tools accept "man tool"; that's actually 3 letters less typing. > >Indeed; and for a concise "Usage" message, "tool -?" often (if >not always) does the trick. (I generally find the tool --help output unhelpful; it's generally to terse and unstructured) Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to include dirfd(3C) into OpenSolaris
On Thursday 22 March 2007 15:03, [EMAIL PROTECTED] wrote: > >On Thursday 22 March 2007 10:21, Joerg Schilling wrote: > >> But BTW: dirfd() would be just: > >> > >> #define dirfd(dp) (dp)->dd_fd > > > >This works really well when (dp) is NULL. > > Yes, is will SEGV; is that an issue? Yes. It can return -1 and set EBADF. This would require that it is a function, not a macro. > getc(NULL) also blows up; what is your point? My point is that it should not SEGV on NULL pointer. It should return -1 and set EBADF. --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to include dirfd(3C) into OpenSolaris
>> getc(NULL) also blows up; what is your point?
>
>My point is that it should not SEGV on NULL pointer. It should
>return -1 and set EBADF.
You are wrong; the standard disagrees with you.
What point is there to have obviously broken code do plausible
things?
FILE *fp = fopen("no-such-file", "r");
char c = getc(fp);
Someone who doesn't check the error return of fopen() is likely
to store the \377 character just "read".
What I'd really like to have is a "fascist C library"; one which
employs even more error checking; calling non-async signal safe
function from a signal handler -> KABOOM, always return garbage
in malloc'ed memory and always zapping it when it is freed.
Casper
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] joining Sun
On 22/03/07, Thomas De Schampheleire <[EMAIL PROTECTED]> wrote: pkginfo SUNWman does show: system SUNWman On-Line Manual Pages doesn't this mean it is installed? That's the man command, not the man pages. -- Rasputin :: Jack of All Trades - Master of Nuns http://number9.hellooperator.net/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] joining Sun
Dick Davies wrote: On 22/03/07, Thomas De Schampheleire <[EMAIL PROTECTED]> wrote: pkginfo SUNWman does show: system SUNWman On-Line Manual Pages doesn't this mean it is installed? That's the man command, not the man pages. The SUNWman package contains the man pages for the ON consolidation, other consolidations deliver their man pages in other packages. The /usr/bin/man command is delivered in the SUNWdoc package. -- Darren J Moffat ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to include dirfd(3C) into OpenSolaris
On Thursday 22 March 2007 15:42, [EMAIL PROTECTED] wrote: > >> getc(NULL) also blows up; what is your point? > > > >My point is that it should not SEGV on NULL pointer. It should > >return -1 and set EBADF. > > You are wrong; the standard disagrees with you. 7.19.7.5.3: The [getc] function returns the next characted from the input stream pointed to by [stream]. If the stream is at end-of-file, the end-of-file indicator for the stream is set and [getc] returns EOF. If a read error occurs, the error indicator for the stream is set and [getc] returns EOF. Where does the standard disagree ? --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] joining Sun
>On 22/03/07, Thomas De Schampheleire <[EMAIL PROTECTED]> wrote: > >> pkginfo SUNWman does show: >> system SUNWman On-Line Manual Pages >> >> doesn't this mean it is installed? > >That's the man command, not the man pages. It's about 12700 manpages too. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to include dirfd(3C) into OpenSolaris
Stefan Teleman writes: > On Thursday 22 March 2007 15:42, [EMAIL PROTECTED] wrote: > > >> getc(NULL) also blows up; what is your point? > > > > > >My point is that it should not SEGV on NULL pointer. It should > > >return -1 and set EBADF. > > > > You are wrong; the standard disagrees with you. > > 7.19.7.5.3: > > The [getc] function returns the next characted from the input stream > pointed to by [stream]. If the stream is at end-of-file, the > end-of-file indicator for the stream is set and [getc] returns EOF. > If a read error occurs, the error indicator for the stream is set and > [getc] returns EOF. > > Where does the standard disagree ? NULL isn't an input stream. Also note the lack of an 'EFAULT' entry in the possible return values, and that 'EBADF' talks about the validity of the file descriptor underlying the stream. As NULL isn't a stream, there is no such file descriptor, nor can it be valid or invalid. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to include dirfd(3C) into OpenSolaris
>On Thursday 22 March 2007 15:42, [EMAIL PROTECTED] wrote: >> >> getc(NULL) also blows up; what is your point? >> > >> >My point is that it should not SEGV on NULL pointer. It should >> >return -1 and set EBADF. >> >> You are wrong; the standard disagrees with you. > >7.19.7.5.3: > >The [getc] function returns the next characted from the input stream >pointed to by [stream]. If the stream is at end-of-file, the >end-of-file indicator for the stream is set and [getc] returns EOF. >If a read error occurs, the error indicator for the stream is set and >[getc] returns EOF. > >Where does the standard disagree ? You quoted a very narrow bit of the standard. But even from this bit you can tell that you are wrong; it is talking about a [stream]. You don't pass a [stream]. You pass NULL. Tell me, how does one set the error indicator on NULL? What possible sense does the first sentence make when you evaluate "input stream pointed to by NULL"? It's for this reason that standards spend some time discussing undefined behaviour; the behaviour of getc is defined *when you pass a stream*. You don't pass a stream, then you don't play and the definition of getc() is irrelevant. Casting something to FILE * does not magically make them streams. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to include dirfd(3C) into OpenSolaris
Stefan Teleman <[EMAIL PROTECTED]> wrote: > On Thursday 22 March 2007 15:42, [EMAIL PROTECTED] wrote: > > >> getc(NULL) also blows up; what is your point? > > > > > >My point is that it should not SEGV on NULL pointer. It should > > >return -1 and set EBADF. > > > > You are wrong; the standard disagrees with you. > > 7.19.7.5.3: > > The [getc] function returns the next characted from the input stream > pointed to by [stream]. If the stream is at end-of-file, the > end-of-file indicator for the stream is set and [getc] returns EOF. > If a read error occurs, the error indicator for the stream is set and > [getc] returns EOF. NULL is no valid stream. A valid stream that is in a special state is something completely different from a wrong object. 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 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Proposal to include dirfd(3C) into OpenSolaris
Question in my mind would be whether any existing implementation allows a NULL argument (and presumably returns -1 then), and also whether there's enough known about the direction of the POSIX draft to know whether it would allow that behavior. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Proposal to include dirfd(3C) into OpenSolaris
And to try to answer my own question, Draft 2 says (about dirfd() among others): ...shall be declared as functions and may also be defined as macros. Function prototypes shall be provided. and specifically about dirfd(): The dirfd( ) function may fail if: [EINVAL] The dirp argument does not refer to a valid directory stream. So: it has to be a function and not just a macro. A prototype is needed in dirent.h. dirfd() may apparently check whether its argument is not a valid directory stream, returning -1 with errno set to EINVAL if not. I don't happen to know the "correct" way to set errno within a function intended to be part of libc, but I'm sure someone does. Other than that, it looks straightforward. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Proposal to include dirfd(3C) into OpenSolaris
"Richard L. Hamilton" <[EMAIL PROTECTED]> wrote: > And to try to answer my own question, Draft 2 says > (about dirfd() among others): > > ...shall be declared as functions and may also be defined as macros. Function > prototypes shall be provided. > > and specifically about dirfd(): > > The dirfd( ) function may fail if: > [EINVAL] The dirp argument does not refer to a valid directory stream. May is not "must" ;-) 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 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Proposal to include dirfd(3C) into OpenSolaris
On Thursday 22 March 2007 18:23, Joerg Schilling wrote: > > The dirfd( ) function may fail if: > > [EINVAL] The dirp argument does not refer to a valid directory > > stream. > > May is not "must" ;-) It isn't "can't" or "shouldtn't" either. --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Proposal to include dirfd(3C) into OpenSolaris
Stefan Teleman writes: > On Thursday 22 March 2007 18:23, Joerg Schilling wrote: > > > > The dirfd( ) function may fail if: > > > [EINVAL] The dirp argument does not refer to a valid directory > > > stream. > > > > May is not "must" ;-) > > It isn't "can't" or "shouldtn't" either. Right, but testing for NULL is still wrong, for the reasons cited before. Chief among them is that it allows poorly-written applications to plow ahead and do additional damage. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] What is OpenSolaris success?
> "Jörg" == Joerg Schilling <[EMAIL PROTECTED]> writes: >> *Bzzz* *whrrr* Jörg> How do you pronounce this? Uh... like they're spelled...? ;-) Just think electromechanical Borg-ish sounds. cheers, mike ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Fire!! core dumped!
Thanks!! More information: Hi, All, Here is the pstack information from dbx. [EMAIL PROTECTED] ([EMAIL PROTECTED]) terminated by signal SEGV (access to address exceeded protections) 0xfd90b258: _lock_try_adaptive : ldstub [%o0 + 12], %o1 (dbx) where current thread: [EMAIL PROTECTED] =>[1] _lock_try_adaptive(0x10018, 0x2089c, 0x64d530, 0x85e18, 0xffbef338, 0x20bd288), at 0xfd90b258 [2] _ti_pthread_mutex_lock(0x0, 0xfd91c000, 0x10018, 0x3, 0x0, 0x0), at 0xfd8fb798 [3] cmgCall::sendEventIn(0x224e010, 0x2, 0x209144b, 0x3, 0x10018, 0x6ef910), at 0xfe4912bc [4] cmgSs7Adapter::inputNetMsg(0xfe50db20, 0x2091430, 0xfe5f677c, 0x3, 0x1a7d5e0, 0xfe5b85c4), at 0xfe50d060 [5] cmgCallMgr::forwardNetEvent(0x28b010, 0xaf6f10, 0x100a, 0x100b, 0xfe5526eb, 0x0), at 0xfe4a6c40 [6] engIOS_EvtHdlr::handleEvent(0x25e1f0, 0xaf6f10, 0x0, 0xbd07c, 0x5, 0x2), at 0xfe1f4a7c [7] XEEvtDispatcher::run(0x1b9010, 0xdce170, 0x1b9124, 0x1b9078, 0x1, 0x710381), at 0xfe96bac4 [8] XEProcShell::run(0x1b69a0, 0x800, 0x9a8, 0xfea06630, 0x1bb610, 0x1), at 0xfe991ce8 [9] main(0x3, 0xffbefb54, 0xffbefb64, 0x1617d0, 0x0, 0x0), at 0x26238 (dbx) regs current thread: [EMAIL PROTECTED] current frame: [1] g0-g10x 0x 0x 0x0001b000 g2-g30x 0x0001 0x 0xfe8ead08 g4-g50x 0x0074 0x 0xffbef32c g6-g70x 0x 0x 0x00193778 o0-o10x 0x00010018 0x 0x0002089c o2-o30x 0x0064d530 0x 0x00085e18 o4-o50x 0xffbef338 0x 0x020bd288 o6-o70x 0xffbef318 0x 0xfd8fb798 l0-l30x 0xfcfc35e4 0x0009 0x l4-l70x0064d530 0xfe8db0e8 0x0064d530 0xfe5b85c4 i0-i30x 0xfd91c000 0x00010018 0x0003 i4-i70x 0x 0xffbef378 0xfe4912bc y0x000f7c26 psr 0xfe401001 pc 0xfd90b258:_lock_try_adaptive ldstub [%o0 + 12], %o1 npc 0xfd90b25c:_lock_try_adaptive+0x4 tst %o1 (dbx) lwps o>[EMAIL PROTECTED] signal SIGSEGV in _lock_try_adaptive() [EMAIL PROTECTED] LWP suspended in _libc_sigaction() [EMAIL PROTECTED] LWP suspended in ___lwp_cond_wait() [EMAIL PROTECTED] LWP suspended in ___lwp_cond_wait() [EMAIL PROTECTED] LWP suspended in private___lwp_cond_wait() [EMAIL PROTECTED] LWP suspended in writeValue() [EMAIL PROTECTED] LWP suspended in __door_call() (dbx) Could you help investigate it? Thanks! Eric This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] more generic firmware download software for Hitachi FC drive?
I know there's a downloader in the patch 116464-02, but what I've got is a 2nd-hand DK32EJ-72FC that has NetApp firmware on it, that I just put in my Sun Blade 2000; and (if it's possible without trashing the drive), I'd prefer to put the Sun firmware on it. However, the downloader AFAIK will only download to drives with the expected inquiry data (matching model and such); if the firmware on the drive identifies it otherwise, in this case as Vendor: NETAPP Product: X235_HJURD073F10 Revision: NA06 it will (sensibly enough) leave it alone. Is either (a) the source for the download program in that patch available somewhere, or (b) some other more generic download program available somewhere, and does anyone know whether the firmware upgrade I have in mind would work? I already had to low-level format the drive to (according to format) change the physical block size to 512. It's doing well enough now on a surface scan, but I'm thinking I'd have less problems with Sun's firmware, if possible. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] more generic firmware download software for Hitachi FC drive?
Richard L. Hamilton wrote: I know there's a downloader in the patch 116464-02, but what I've got is a 2nd-hand DK32EJ-72FC that has NetApp firmware on it, that I just put in my Sun Blade 2000; and (if it's possible without trashing the drive), I'd prefer to put the Sun firmware on it. However, the downloader AFAIK will only download to drives with the expected inquiry data (matching model and such); if the firmware on the drive identifies it otherwise, in this case as Vendor: NETAPP Product: X235_HJURD073F10 Revision: NA06 it will (sensibly enough) leave it alone. Is either (a) the source for the download program in that patch available somewhere, Nope - these things tend to be manufacturer-specific and held tightly. > or (b) some other more generic download program available somewhere Not as such, no. There have been requests for such a thing in the past but I don't think they've been accepted - for a variety of reasons. and does anyone know whether the firmware upgrade I have in mind would work? Unlikely - there's no guarantee that the drive vendor hasn't done something funky to enable the NetApp vid/pid/rev, let alone anything else that NetApp as the VAR might want implemented. James C. McPherson -- Solaris kernel software engineer Sun Microsystems ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Update to B60 ?
How to update to Nevada b60 ? This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to include dirfd(3C) into OpenSolaris
[EMAIL PROTECTED] wrote: [...] Strictly conformant to the above would therefore be: #define dirfd(dp) ((dp) ? (dp)->dd_fd : -1) No. Nothing to do with strictly conformant; while it is possible to have a DIR * which is NULL, using it immediately gets you undefined behaviour. IMHO, implementations MUST NOT protect against that; that way madness and buggy programs lie. As a related note glibc has some questionable protections, like free(NULL) which it simply ignores resulting in bugs remaining hidden. GNU ls does a free(NULL) somewhere which we discovered while demoing truss on linux processes in BrandZ. It is also visible when you use ltrace in Linux. Regards, Moinak. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Proposal to include dirfd(3C) into OpenSolaris
>And to try to answer my own question, Draft 2 says >(about dirfd() among others): > >...shall be declared as functions and may also be defined as macros. Function >prototypes shall be provided. > >and specifically about dirfd(): > >The dirfd( ) function may fail if: >[EINVAL] The dirp argument does not refer to a valid directory stream. None of readdir/opendir have this return value. Note also that it says "may fail"; so returning failure on NULL is allowed as is SIGSEGV; IMHO, the latter is still prefered. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to include dirfd(3C) into OpenSolaris
Moinak Ghosh wrote: > [EMAIL PROTECTED] wrote: > >> [...] >> >>> Strictly conformant to the above would therefore be: >>> >>> #definedirfd(dp)((dp) ? (dp)->dd_fd : -1) >>> >> >> >> No. Nothing to do with strictly conformant; while it is possible >> to have a DIR * which is NULL, using it immediately gets you undefined >> behaviour. >> >> IMHO, implementations MUST NOT protect against that; that way madness >> and buggy programs lie. >> > > > As a related note glibc has some questionable protections, like > free(NULL) > which it simply ignores resulting in bugs remaining hidden. GNU ls > does a > free(NULL) somewhere which we discovered while demoing truss on linux > processes in BrandZ. It is also visible when you use ltrace in Linux. > free(NULL) is a legal no-opp in C. Ian ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
