Re: [osol-discuss] File Events Notification API - PSARC/2007/027
I notice that over time, rcapd can consume a fair amount of cpu, even though at any given time, it uses a reasonable enough amount. Is there any way FEN could be used to make it more efficient? Like using FEN to monitor its config file(s) rather than repeatedly stat() or whatever? Or if FEN could be used /proc in such a way as to avoid other reasons for rcapd possibly having to loop over a set of process related info? It just strikes me that in in a perfect world, rcapd would be purely event-driven, and passive unless an event informed it of the need to intervene or to update its stats. As such, it's CPU usage would increase only with churn in the resources it controlled, but would otherwise grow very little with larger numbers of projects, zones, and ultimately processes to watch; which, although I haven't looked at it operating on different scales, I suspect isn't the case now. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] File Events Notification API - PSARC/2007/027
Robert Milkowski wrote: > Hello prakash, > > Thank you for information. I'll check with perf-discuss@ to see if > there're any examples how to use it. > I am trying to make this case public. The case material will have man page documentation on how to use these interfaces. I will provide more details and examples thru my blog later. > When it comes to ARC cases - should it be better with all new ARC cases > would be made public by default, and only if necessary one would not > be public instead of trying to make one public every time. IIRC > someone from Sun already has pointed that it should be the case > (all new ARC cases should be public). > > Yes, I think so. The process is being streamlined now. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] File Events Notification API - PSARC/2007/027
Hello Alan, Wednesday, August 8, 2007, 3:52:31 PM, you wrote: AC> Robert Milkowski wrote: >> Hello prakash, >> >> Thank you for information. I'll check with perf-discuss@ to see if >> there're any examples how to use it. >> >> When it comes to ARC cases - should it be better with all new ARC cases >> would be made public by default, and only if necessary one would not >> be public instead of trying to make one public every time. IIRC >> someone from Sun already has pointed that it should be the case >> (all new ARC cases should be public). AC> The tool we use to file ARC fasttracks was changed a few months ago to AC> ask if cases should be open or closed, and if the user chooses closed, AC> explain why. Before that, making a case open required manual intervention AC> which many ARC case submitters didn't know how to do, so many were made AC> closed that shouldn't be - that should hopefully happen much less often AC> now (for fasttracks at least). Thanks! That should improve things I guess :) Probably there should be a pop-up with 'you're encourage to make it public' - ok, I'm kidding about pop-up :) -- Best regards, Robert Milkowski mailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] File Events Notification API - PSARC/2007/027
Robert Milkowski wrote: > Hello prakash, > > Thank you for information. I'll check with perf-discuss@ to see if > there're any examples how to use it. > > When it comes to ARC cases - should it be better with all new ARC cases > would be made public by default, and only if necessary one would not > be public instead of trying to make one public every time. IIRC > someone from Sun already has pointed that it should be the case > (all new ARC cases should be public). The tool we use to file ARC fasttracks was changed a few months ago to ask if cases should be open or closed, and if the user chooses closed, explain why. Before that, making a case open required manual intervention which many ARC case submitters didn't know how to do, so many were made closed that shouldn't be - that should hopefully happen much less often now (for fasttracks at least). -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] File Events Notification API - PSARC/2007/027
Hello prakash, Thank you for information. I'll check with perf-discuss@ to see if there're any examples how to use it. When it comes to ARC cases - should it be better with all new ARC cases would be made public by default, and only if necessary one would not be public instead of trying to make one public every time. IIRC someone from Sun already has pointed that it should be the case (all new ARC cases should be public). -- Best regards, Robertmailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] File Events Notification API - PSARC/2007/027
Milan Jurik writes: > You have good opportunity to discuss the most of features in psarc > process before integration. And in many cases even in stages like "one > page". But it is project team decision if they want to work on their > project in private group or not. Like in the rest of world. And I don't > agree that this level of freedom is bad thing. There are certainly cases where working exclusively in the open may be too much -- integrating a small bug fix, for example -- or where it's just impossible -- such as in modifying usr/closed. The process should "shrink to fit" the application, rather than being a noose. However, I do think the expected default (particularly for Sun employees) should be to do things in the open. This means that if there's an I-team mailing list, it's on some open site (such as opensolaris.org). If there's a project source repository or documentation, then that's kept in the open. Schedules and lists of people involved should be open. If there's an organized code review effort, then that's in the open. And so on. Particularly given Sun's at times haphazard relationship with the concept of open source, it seems quite likely that there are more than a few who doubt our intentions, and I think it's very important that we aim for best practices in the work we do. Even more so, when there are alternative open projects (such as BSD and GNU/Linux) where contributors could go instead, we need to be even better. And I feel that we should begin to view projects that are less open with some skepticism. Certainly, there's a transition that's still in process, with some groups and projects being less "open" than others, and this should improve with time, but we do need to start setting high standards, and asking questions. Opensolaris.org isn't just a marketing gimmick. It's not just a "user group" or way for Sun engineers to contact customers directly. Instead, it's a software development community, and the elements of development (direct access to project gates, open discussion of requirements and design, and so on) need to be present. -- 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] File Events Notification API - PSARC/2007/027
On Tue, 2007-08-07 at 15:35 +0200, Milan Jurik wrote: > Hi Matthew, > > V út, 07. 08. 2007 v 14:40, Kaiwai Gardiner pÃÅ¡e: > > On Tue, 2007-08-07 at 08:25 +0200, Milan Jurik wrote: > > > > > > But this happend, the responsible engineer took related RFE and you > > > could see that on bugs.opensolaris.org. I agree with one thing - bugster > > > is very good tool, but its public interface is not very useful in case > > > that you want to monitor some CR. > > > > Hence my leaning towards Bugzilla - people give it a hard time but it is > > easy to keep track of favourite bugs etc. etc. Much more > > 'collabortative' - you can actually update submissions etc. etc. all of > > that should be available on the bugster. > > > > It is in bugster, in very good way (in my oppinion). But bugster is not > open and that is the root cause of many issues, missing open CR > management. If its available, how do I keep track of it? how do I update submitted bug reports? > > > > > And I don't know why File Events Notification API - PSARC/2007/027 is > > > > > not public. You can see who made the putback - ask him, maybe he is > > > > > not > > > > > reading this list. > > > > > > > > Its very hard to know when there is no name attached to the put back as > > > > far as I see. > > > > > > > > > > http://mail.opensolaris.org/pipermail/onnv-notify/2007-April/007227.html > > > > > > -> 6381975 solaris need centrino ipw3945 wifi support > > > > > > http://bugs.opensolaris.org/view_bug.do?bug_id=6381975 > > > > But these are hardly 'visable' forms of communication; its like saying, > > 'yes, there is documentation, read the source code'. > > > > I said it is possible, you must be more active. > > > > -> now you know ;-) > > > > > > And I think that Brian is very active even in community to help people > > > with this driver :-) He just worked hard to release something and even > > > at that time he was ready to communicate with those who wrote e-mail to > > > him (I know it :-) ). > > > > Then maybe its the opensolaris.org website maintainers not willing to > > create some buzz about what is being worked on. > > > > It is not osol.org website maintainers responsibility. > > > > That's typically PSARC and sometimes updates in Bugster. E.g. manpage is > > > written after driver completition. Which docu? > > > > The SPARC information before putting the code in. When it appears on the > > ONNV change, I want to be able to read about it straight away. > > > > Push on exact PSARC authors. > > > > > Communication doesn't have to go overboard, but a quick, 'this what > > we're doing now' would suffice - atleast show there is some pulse in the > > body - I go past parts of opensolaris.org and wonder if any of the > > people involved are alive because its so quiet. > > > > I think there is good pulse in the body and you can see that in many > projects on osol.org, you should monitor more than just > opensolaris-discuss list. > > This is open source world, nobody should dictate to others on which > level they are communicating. I came from open source world and know the > difference. I'm not dictating, just fed up with the whining that Linux gets all the mindshare and yet there is a lack of cheerleading pulling in the developers - sometimes you need to have some 'temptations' hanging on the outside to bring people in. To get customers/endusers and developers, you actually have to do something - when a new user or developer asks a question, don't abuse him to buggery and claim he is the one with the problem. Listen, absorb and converse. Solaris isn't an 'extension' of ones inner being, its an operating system. So when someone does criticise Solaris, take it on board. Matthew ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] File Events Notification API - PSARC/2007/027
Hi Joerg, V út, 07. 08. 2007 v 15:03, Joerg Schilling píše: > Milan Jurik <[EMAIL PROTECTED]> wrote: > > > > > Did you look at RFEs? Did you look at PSARCs? Did you look at projects > > > > on opensolaris.org? And can you show me some really big project where > > > > all developers are informing community about their actual work and > > > > future plans? > > > > > > Umm, Linux ? > > > > Are you sure about this? I spent lots of time in lkml... Lots of patches > > (even bigger) are comming "from sky". > > Do we need to repeat mistakes from the Linux world? > You have some parser for keyword "Linux" ;-) You have good opportunity to discuss the most of features in psarc process before integration. And in many cases even in stages like "one page". But it is project team decision if they want to work on their project in private group or not. Like in the rest of world. And I don't agree that this level of freedom is bad thing. Best regards, Milan ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] File Events Notification API - PSARC/2007/027
Hi Matthew, V út, 07. 08. 2007 v 14:40, Kaiwai Gardiner píše: > On Tue, 2007-08-07 at 08:25 +0200, Milan Jurik wrote: > > > > But this happend, the responsible engineer took related RFE and you > > could see that on bugs.opensolaris.org. I agree with one thing - bugster > > is very good tool, but its public interface is not very useful in case > > that you want to monitor some CR. > > Hence my leaning towards Bugzilla - people give it a hard time but it is > easy to keep track of favourite bugs etc. etc. Much more > 'collabortative' - you can actually update submissions etc. etc. all of > that should be available on the bugster. > It is in bugster, in very good way (in my oppinion). But bugster is not open and that is the root cause of many issues, missing open CR management. > > > > And I don't know why File Events Notification API - PSARC/2007/027 is > > > > not public. You can see who made the putback - ask him, maybe he is not > > > > reading this list. > > > > > > Its very hard to know when there is no name attached to the put back as > > > far as I see. > > > > > > > http://mail.opensolaris.org/pipermail/onnv-notify/2007-April/007227.html > > > > -> 6381975 solaris need centrino ipw3945 wifi support > > > > http://bugs.opensolaris.org/view_bug.do?bug_id=6381975 > > But these are hardly 'visable' forms of communication; its like saying, > 'yes, there is documentation, read the source code'. > I said it is possible, you must be more active. > > -> now you know ;-) > > > > And I think that Brian is very active even in community to help people > > with this driver :-) He just worked hard to release something and even > > at that time he was ready to communicate with those who wrote e-mail to > > him (I know it :-) ). > > Then maybe its the opensolaris.org website maintainers not willing to > create some buzz about what is being worked on. > It is not osol.org website maintainers responsibility. > > That's typically PSARC and sometimes updates in Bugster. E.g. manpage is > > written after driver completition. Which docu? > > The SPARC information before putting the code in. When it appears on the > ONNV change, I want to be able to read about it straight away. > Push on exact PSARC authors. > > Communication doesn't have to go overboard, but a quick, 'this what > we're doing now' would suffice - atleast show there is some pulse in the > body - I go past parts of opensolaris.org and wonder if any of the > people involved are alive because its so quiet. > I think there is good pulse in the body and you can see that in many projects on osol.org, you should monitor more than just opensolaris-discuss list. This is open source world, nobody should dictate to others on which level they are communicating. I came from open source world and know the difference. Best regards, Milan ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] File Events Notification API - PSARC/2007/027
Milan Jurik <[EMAIL PROTECTED]> wrote: > > > Did you look at RFEs? Did you look at PSARCs? Did you look at projects > > > on opensolaris.org? And can you show me some really big project where > > > all developers are informing community about their actual work and > > > future plans? > > > > Umm, Linux ? > > Are you sure about this? I spent lots of time in lkml... Lots of patches > (even bigger) are comming "from sky". Do we need to repeat mistakes from the Linux world? 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] File Events Notification API - PSARC/2007/027
On Tue, 2007-08-07 at 08:25 +0200, Milan Jurik wrote: > Hi Matthew, > > Kaiwai Gardiner pÃÅ¡e v út 07. 08. 2007 v 15:36 +1200: > > On Mon, 2007-08-06 at 20:09 +0200, Milan Jurik wrote: > > > Hi Matthew, > > > > > > I know I'm not right man who should answer you, as I'm from Sun... But > > > look at it from another perspective: > > > > > > V po, 06. 08. 2007 v 19:18, Kaiwai Gardiner pÃÅ¡e: > > > > Agreed, but at the same driver - are drivers *truely* that secret? I > > > > mean, wpi for 3945 was developed in 'secret' - why? what possible loss > > > > of competitive advantage would it yield? looking at it from my angle, > > > > all I see are positives by way of consumers actually seeing and knowing > > > > that Sun are making/porting drivers to Solaris. > > > > > > > > > > Are you sure that Sun employees had access to 3945 development except > > > the developer of it? The most of them didn't know about it. And it is > > > way how distributed development happens - somebody (or some team) is > > > working on something till point it is "compilable" or "usable" or just > > > "publicable". The level of this point is on the developer decision, as > > > usual in open source world. Some developers are publishing all their > > > steps, some are publishing something usefull for users. You had the > > > access to source code of wpi at the same time as the most of Sun > > > employees. Today you can find on bugs.opensolaris.org the responsible > > > engineer for all accepted RFEs, why not to contact him if you want to > > > help with development and/or testing of some particular RFE? > > > > BUt at the same time - if the 'community' knew that wpi was being worked > > on - Sun might have actually found people helping port it to Solaris :-) > > > > A small hear-ye hear-ye would have been on order. > > > > But this happend, the responsible engineer took related RFE and you > could see that on bugs.opensolaris.org. I agree with one thing - bugster > is very good tool, but its public interface is not very useful in case > that you want to monitor some CR. Hence my leaning towards Bugzilla - people give it a hard time but it is easy to keep track of favourite bugs etc. etc. Much more 'collabortative' - you can actually update submissions etc. etc. all of that should be available on the bugster. > > > And I don't know why File Events Notification API - PSARC/2007/027 is > > > not public. You can see who made the putback - ask him, maybe he is not > > > reading this list. > > > > Its very hard to know when there is no name attached to the put back as > > far as I see. > > > > http://mail.opensolaris.org/pipermail/onnv-notify/2007-April/007227.html > > -> 6381975 solaris need centrino ipw3945 wifi support > > http://bugs.opensolaris.org/view_bug.do?bug_id=6381975 But these are hardly 'visable' forms of communication; its like saying, 'yes, there is documentation, read the source code'. > -> now you know ;-) > > And I think that Brian is very active even in community to help people > with this driver :-) He just worked hard to release something and even > at that time he was ready to communicate with those who wrote e-mail to > him (I know it :-) ). Then maybe its the opensolaris.org website maintainers not willing to create some buzz about what is being worked on. > > > > Things should be merged into the public tree, just like they're merged > > > > inside the company. Everything that occurs inside Sun should occur at > > > > the same time on the other side - if a case log as been updated, then it > > > > should be accessible to the public. > > > > > > > > > > But wpi wasn't merged to Sun tree significantly sooner (it tooks few > > > minutes, that sync between ON gate inside and outside). The developer > > > worked on his source code in his own workspace. As usual. > > > > Would it be better to put documentation out there before the code? > > > > That's typically PSARC and sometimes updates in Bugster. E.g. manpage is > written after driver completition. Which docu? The SPARC information before putting the code in. When it appears on the ONNV change, I want to be able to read about it straight away. > > > > Its all about transparency in the development process; and if it means > > > > that developers think out aloud on ideas - I'd sooner see Sun > > > > programmers conduct regular brain farts on a blog and know there is some > > > > cranium activity about future Solaris development than just sitting on > > > > the side lines praying something is occurring in the deep crypt of Sun. > > > > > > > > > > Did you look at RFEs? Did you look at PSARCs? Did you look at projects > > > on opensolaris.org? And can you show me some really big project where > > > all developers are informing community about their actual work and > > > future plans? > > > > > > Please, leave the decision about their openness on developers. Some > > > prefer public development (lots of Sun employee), some are working in > > > t
Re: [osol-discuss] File Events Notification API - PSARC/2007/027
Kaiwai Gardiner wrote: > On Mon, 2007-08-06 at 20:09 +0200, Milan Jurik wrote: >> And I don't know why File Events Notification API - PSARC/2007/027 is >> not public. You can see who made the putback - ask him, maybe he is not >> reading this list. > > Its very hard to know when there is no name attached to the put back as > far as I see. The onnv-notify mail about the putback lists the committers name: http://mail.opensolaris.org/pipermail/onnv-notify/2007-July/012243.html -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] File Events Notification API - PSARC/2007/027
Hi Matthew, Kaiwai Gardiner pÃÅ¡e v út 07. 08. 2007 v 15:36 +1200: > On Mon, 2007-08-06 at 20:09 +0200, Milan Jurik wrote: > > Hi Matthew, > > > > I know I'm not right man who should answer you, as I'm from Sun... But > > look at it from another perspective: > > > > V po, 06. 08. 2007 v 19:18, Kaiwai Gardiner pÃÅ¡e: > > > Agreed, but at the same driver - are drivers *truely* that secret? I > > > mean, wpi for 3945 was developed in 'secret' - why? what possible loss > > > of competitive advantage would it yield? looking at it from my angle, > > > all I see are positives by way of consumers actually seeing and knowing > > > that Sun are making/porting drivers to Solaris. > > > > > > > Are you sure that Sun employees had access to 3945 development except > > the developer of it? The most of them didn't know about it. And it is > > way how distributed development happens - somebody (or some team) is > > working on something till point it is "compilable" or "usable" or just > > "publicable". The level of this point is on the developer decision, as > > usual in open source world. Some developers are publishing all their > > steps, some are publishing something usefull for users. You had the > > access to source code of wpi at the same time as the most of Sun > > employees. Today you can find on bugs.opensolaris.org the responsible > > engineer for all accepted RFEs, why not to contact him if you want to > > help with development and/or testing of some particular RFE? > > BUt at the same time - if the 'community' knew that wpi was being worked > on - Sun might have actually found people helping port it to Solaris :-) > > A small hear-ye hear-ye would have been on order. > But this happend, the responsible engineer took related RFE and you could see that on bugs.opensolaris.org. I agree with one thing - bugster is very good tool, but its public interface is not very useful in case that you want to monitor some CR. > > > I mean, if they're going to worry about 'competitive advantage' then why > > > announce to the world support for a product that doesn't yet exist in > > > the marketplace/still in development? > > > > > > > I don't think that in wpi case it was about competitive advantage. It > > was just way how the most of drivers in open source are developed - by > > some small team (typically with just one member), which is publishing > > their results when they are ready for public, per their decision. You > > can go and ask for source codes earlier if you want. And maybe the team > > will do it for you. > > But the driver is opensource and ported by Sun - I know about the > existance of wpi, what I didn't know about was Sun porting it to > Solaris. > Because you didn't monitor the RFE probably. Otherwise you would see that something happend and one man started to work on it. I know, not very simple these days. But still possible. > > And I don't know why File Events Notification API - PSARC/2007/027 is > > not public. You can see who made the putback - ask him, maybe he is not > > reading this list. > > Its very hard to know when there is no name attached to the put back as > far as I see. > http://mail.opensolaris.org/pipermail/onnv-notify/2007-April/007227.html -> 6381975 solaris need centrino ipw3945 wifi support http://bugs.opensolaris.org/view_bug.do?bug_id=6381975 -> now you know ;-) And I think that Brian is very active even in community to help people with this driver :-) He just worked hard to release something and even at that time he was ready to communicate with those who wrote e-mail to him (I know it :-) ). > > > Things should be merged into the public tree, just like they're merged > > > inside the company. Everything that occurs inside Sun should occur at > > > the same time on the other side - if a case log as been updated, then it > > > should be accessible to the public. > > > > > > > But wpi wasn't merged to Sun tree significantly sooner (it tooks few > > minutes, that sync between ON gate inside and outside). The developer > > worked on his source code in his own workspace. As usual. > > Would it be better to put documentation out there before the code? > That's typically PSARC and sometimes updates in Bugster. E.g. manpage is written after driver completition. Which docu? > > > Its all about transparency in the development process; and if it means > > > that developers think out aloud on ideas - I'd sooner see Sun > > > programmers conduct regular brain farts on a blog and know there is some > > > cranium activity about future Solaris development than just sitting on > > > the side lines praying something is occurring in the deep crypt of Sun. > > > > > > > Did you look at RFEs? Did you look at PSARCs? Did you look at projects > > on opensolaris.org? And can you show me some really big project where > > all developers are informing community about their actual work and > > future plans? > > > > Please, leave the decision about their openness on develop
Re: [osol-discuss] File Events Notification API - PSARC/2007/027
Sending it again.. my reply got lost... I am the person working on this feature. Briefly, the File Events Notification(FEN) facility provides means to monitor a file or directory for changes. The API is based on the event ports(the event notification framework) that was introduced in Solaris 10. The FEN facility will be added as an event source to the event notification framework. It is similar to FAM(SGI)/Gamin. But from what I know, FAM & Gamin, are user land implementations as a file monitoring services. They in turn use kernel file monitoring mechanisms like 'kqueues'(BSD), 'inotify'(on Linux) and 'imon'(SGI). On systems where such kernel mechanisms are not present it just polls. The FEN facility being added to Solaris is a kernel mechanism. Using these interfaces, applications can register files and directories to be monitored for changes and receive an event notification, via an event port, when change occurs. In that sense, it is similar to 'kqueues', 'inotify', 'imon', file monitoring mechanisms. There has been discussion regarding File Event Notification on the performance community forum ' [EMAIL PROTECTED]'. With regards to why is this case not public - You may have noticed, not all cases are discussed in public. We are still transitioning into the open development model. More and more cases are being discussed in public. I can certainly try and find out if we can make the case materials for this case public. -Prakash. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] File Events Notification API - PSARC/2007/027
On Mon, 2007-08-06 at 20:09 +0200, Milan Jurik wrote: > Hi Matthew, > > I know I'm not right man who should answer you, as I'm from Sun... But > look at it from another perspective: > > V po, 06. 08. 2007 v 19:18, Kaiwai Gardiner pÃÅ¡e: > > Agreed, but at the same driver - are drivers *truely* that secret? I > > mean, wpi for 3945 was developed in 'secret' - why? what possible loss > > of competitive advantage would it yield? looking at it from my angle, > > all I see are positives by way of consumers actually seeing and knowing > > that Sun are making/porting drivers to Solaris. > > > > Are you sure that Sun employees had access to 3945 development except > the developer of it? The most of them didn't know about it. And it is > way how distributed development happens - somebody (or some team) is > working on something till point it is "compilable" or "usable" or just > "publicable". The level of this point is on the developer decision, as > usual in open source world. Some developers are publishing all their > steps, some are publishing something usefull for users. You had the > access to source code of wpi at the same time as the most of Sun > employees. Today you can find on bugs.opensolaris.org the responsible > engineer for all accepted RFEs, why not to contact him if you want to > help with development and/or testing of some particular RFE? BUt at the same time - if the 'community' knew that wpi was being worked on - Sun might have actually found people helping port it to Solaris :-) A small hear-ye hear-ye would have been on order. > > I mean, if they're going to worry about 'competitive advantage' then why > > announce to the world support for a product that doesn't yet exist in > > the marketplace/still in development? > > > > I don't think that in wpi case it was about competitive advantage. It > was just way how the most of drivers in open source are developed - by > some small team (typically with just one member), which is publishing > their results when they are ready for public, per their decision. You > can go and ask for source codes earlier if you want. And maybe the team > will do it for you. But the driver is opensource and ported by Sun - I know about the existance of wpi, what I didn't know about was Sun porting it to Solaris. > And I don't know why File Events Notification API - PSARC/2007/027 is > not public. You can see who made the putback - ask him, maybe he is not > reading this list. Its very hard to know when there is no name attached to the put back as far as I see. > > Things should be merged into the public tree, just like they're merged > > inside the company. Everything that occurs inside Sun should occur at > > the same time on the other side - if a case log as been updated, then it > > should be accessible to the public. > > > > But wpi wasn't merged to Sun tree significantly sooner (it tooks few > minutes, that sync between ON gate inside and outside). The developer > worked on his source code in his own workspace. As usual. Would it be better to put documentation out there before the code? > > Its all about transparency in the development process; and if it means > > that developers think out aloud on ideas - I'd sooner see Sun > > programmers conduct regular brain farts on a blog and know there is some > > cranium activity about future Solaris development than just sitting on > > the side lines praying something is occurring in the deep crypt of Sun. > > > > Did you look at RFEs? Did you look at PSARCs? Did you look at projects > on opensolaris.org? And can you show me some really big project where > all developers are informing community about their actual work and > future plans? > > Please, leave the decision about their openness on developers. Some > prefer public development (lots of Sun employee), some are working in > their own workspaces (lots of Sun employee). > > You want just big amount of paperwork from us ;-) I hope the community > is not my second manager asking for weekly reports... Its about communication - I'm generally not a person who likes to communicate anything with anyone - I generally speaking keep people on a 'need to know' basis - but at the same time, there is a need to inform the community on what is happening. Tell the community what they're working on - and shock horror, they might actually find that a few of the great unwashed might actually be interested in contributing. Matthew ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] File Events Notification API - PSARC/2007/027
I am the person working on this feature. Briefly, the File Events Notification(FEN) facility provides means to monitor a file or directory for changes. The API is based on the event ports(the event notification framework) that was introduced in Solaris 10. The FEN facility will be added as an event source to the event notification framework. It is similar to FAM(SGI)/Gamin. But from what I know, FAM & Gamin, are user land implementations as a file monitoring services. They in turn use kernel file monitoring mechanisms like 'kqueues'(BSD), 'inotify'(on Linux) and 'imon'(SGI). On systems where such kernel mechanisms are not present it just polls. The FEN facility being added to Solaris is a kernel mechanism. Use these interfaces applications can register files and directories to be monitored for changes and receive an event notification on an event port when change occurs. In that sense, it is similar to 'kqueues', 'inotify', 'imon', file monitoring mechanisms. There has been discussion regarding File Event Notification on the performance community forum ' [EMAIL PROTECTED]'. With regards to why is this case not public - You may have noticed, not all cases are discussed in public. We are still transitioning into the open development model. More and more cases are being discussed in public. I can certainly try and find out if we can make the case materials for this case public. -Prakash. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] File Events Notification API - PSARC/2007/027
Hi Cyril, > Hi Milan, > > On 8/6/07, Milan Jurik <[EMAIL PROTECTED]> wrote: > > > Did you look at RFEs? Did you look at PSARCs? Did you look at projects > > on opensolaris.org? And can you show me some really big project where > > all developers are informing community about their actual work and > > future plans? > > Umm, Linux ? Are you sure about this? I spent lots of time in lkml... Lots of patches (even bigger) are comming "from sky". > In fact in the open source world it is a matter of etiquette. Why? Why should he publish all his steps? He can go and develop something himself, because he prefers to spend some time just with "his code". Not all are "exhibicionists" (please, read this word in positive way, or just say that I'm Czech who doesn't know English very well :-) ). > Working privately is one's choice, of course. However, it would demonstrate > a disrespect to the rest of the community. Why ? Because at the end of the > work one will, essentially, throw the code over the wall. > Disrespect? Because you want to publish something really working, not just some skeleton? Are you publishing all your "everyday" changes? Could you respect that some developers prefer to "work in bigger steps" and not consulting their everyday steps with others? It is normal even in companies. > > Please, leave the decision about their openness on developers. Some > > prefer public development (lots of Sun employee), some are working in > > their own workspaces (lots of Sun employee). > > We (community) cannot decide for Sun employees how to do their > work for Sun. Nonetheless we can create rules for work integrated > into OpenSolaris. I think it is fair. > Of course. Could you specify one example of rule which will prohibit the integration that somebody is working in his own workspace and going to public just before integration or ARC, please? It is his decision to do it in this way. And potentially very dangerous, because: a) his work must not be accepted by others, as he implemented something in "unpopular" way b) somebody will implement it quicker c-d-e-f-...) add your own points here Is his contribution worse because he decided to not communicate frequently? > > You want just big amount of paperwork from us ;-) I hope the community > > is not my second manager asking for weekly reports... > > That strange conclusion. How did you get to it ? > And what are you asking for in "wpi cases"? And btw. I added some "hints" how to receive FEM API to my previous e-mail, the main topic of this thread. Why are you complaining here? What are you expecting? That our CEO will go and push us in some way? Are you sure that this will make Sun engineers happy members of opensolaris community? We are just people, people with e-mail addresses ;-) Best regards, Milan ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] File Events Notification API - PSARC/2007/027
Hi Milan, On 8/6/07, Milan Jurik <[EMAIL PROTECTED]> wrote: > Did you look at RFEs? Did you look at PSARCs? Did you look at projects > on opensolaris.org? And can you show me some really big project where > all developers are informing community about their actual work and > future plans? Umm, Linux ? In fact in the open source world it is a matter of etiquette. Working privately is one's choice, of course. However, it would demonstrate a disrespect to the rest of the community. Why ? Because at the end of the work one will, essentially, throw the code over the wall. > Please, leave the decision about their openness on developers. Some > prefer public development (lots of Sun employee), some are working in > their own workspaces (lots of Sun employee). We (community) cannot decide for Sun employees how to do their work for Sun. Nonetheless we can create rules for work integrated into OpenSolaris. I think it is fair. > You want just big amount of paperwork from us ;-) I hope the community > is not my second manager asking for weekly reports... That strange conclusion. How did you get to it ? -- Regards, Cyril ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] File Events Notification API - PSARC/2007/027
Hi Matthew, I know I'm not right man who should answer you, as I'm from Sun... But look at it from another perspective: V po, 06. 08. 2007 v 19:18, Kaiwai Gardiner píše: > Agreed, but at the same driver - are drivers *truely* that secret? I > mean, wpi for 3945 was developed in 'secret' - why? what possible loss > of competitive advantage would it yield? looking at it from my angle, > all I see are positives by way of consumers actually seeing and knowing > that Sun are making/porting drivers to Solaris. > Are you sure that Sun employees had access to 3945 development except the developer of it? The most of them didn't know about it. And it is way how distributed development happens - somebody (or some team) is working on something till point it is "compilable" or "usable" or just "publicable". The level of this point is on the developer decision, as usual in open source world. Some developers are publishing all their steps, some are publishing something usefull for users. You had the access to source code of wpi at the same time as the most of Sun employees. Today you can find on bugs.opensolaris.org the responsible engineer for all accepted RFEs, why not to contact him if you want to help with development and/or testing of some particular RFE? > I mean, if they're going to worry about 'competitive advantage' then why > announce to the world support for a product that doesn't yet exist in > the marketplace/still in development? > I don't think that in wpi case it was about competitive advantage. It was just way how the most of drivers in open source are developed - by some small team (typically with just one member), which is publishing their results when they are ready for public, per their decision. You can go and ask for source codes earlier if you want. And maybe the team will do it for you. And I don't know why File Events Notification API - PSARC/2007/027 is not public. You can see who made the putback - ask him, maybe he is not reading this list. > Things should be merged into the public tree, just like they're merged > inside the company. Everything that occurs inside Sun should occur at > the same time on the other side - if a case log as been updated, then it > should be accessible to the public. > But wpi wasn't merged to Sun tree significantly sooner (it tooks few minutes, that sync between ON gate inside and outside). The developer worked on his source code in his own workspace. As usual. > Its all about transparency in the development process; and if it means > that developers think out aloud on ideas - I'd sooner see Sun > programmers conduct regular brain farts on a blog and know there is some > cranium activity about future Solaris development than just sitting on > the side lines praying something is occurring in the deep crypt of Sun. > Did you look at RFEs? Did you look at PSARCs? Did you look at projects on opensolaris.org? And can you show me some really big project where all developers are informing community about their actual work and future plans? Please, leave the decision about their openness on developers. Some prefer public development (lots of Sun employee), some are working in their own workspaces (lots of Sun employee). You want just big amount of paperwork from us ;-) I hope the community is not my second manager asking for weekly reports... Best regards, Milan (not opensolaris developer, "only" Solaris sustainer) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] File Events Notification API - PSARC/2007/027
On Mon, 2007-08-06 at 18:03 +0100, Robert Milkowski wrote: > Hello Kaiwai, > > Monday, August 6, 2007, 11:58:32 AM, you wrote: > > KG> On Mon, 2007-08-06 at 10:37 +0100, Robert Milkowski wrote: > >> Hello Kaiwai, > >> > >> Saturday, August 4, 2007, 4:13:52 AM, you wrote: > >> > >> KG> On Fri, 2007-08-03 at 19:42 +0100, Robert Milkowski wrote: > >> >> Hello opensolaris-discuss, > >> >> > >> >> Can anyone shed some light on it? Maybe PSARC materials can be made > >> >> publicly available? > >> >> > >> > >> KG> The way I interpete it, it is something like FAM which allows things > >> KG> like nautilus to know when something has been change in the file system > >> KG> so that it automatically is shown in the file manager window. > >> > >> I had the same thought still that information should more openly > >> available, more in a spirit of open source > >> > > KG> Unfortunately development by Sun isn't occuring in the public, which > KG> kinda sucks - someone needs to remind Sun what opensource actually > KG> means. > > Some does some not - we should give them credit for all what has been > done so far - it's a huge changeover. > > I can understand that some projects will be developed 'secretely' and > only then integrated - after all Sun is competing in a market. > > However what is a reasoning for not publishing arc case like in that > example with file event notification API? I guess there's none - just > old habits... Agreed, but at the same driver - are drivers *truely* that secret? I mean, wpi for 3945 was developed in 'secret' - why? what possible loss of competitive advantage would it yield? looking at it from my angle, all I see are positives by way of consumers actually seeing and knowing that Sun are making/porting drivers to Solaris. I mean, if they're going to worry about 'competitive advantage' then why announce to the world support for a product that doesn't yet exist in the marketplace/still in development? Things should be merged into the public tree, just like they're merged inside the company. Everything that occurs inside Sun should occur at the same time on the other side - if a case log as been updated, then it should be accessible to the public. Its all about transparency in the development process; and if it means that developers think out aloud on ideas - I'd sooner see Sun programmers conduct regular brain farts on a blog and know there is some cranium activity about future Solaris development than just sitting on the side lines praying something is occurring in the deep crypt of Sun. Matthew ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] File Events Notification API - PSARC/2007/027
Hello Kaiwai, Monday, August 6, 2007, 11:58:32 AM, you wrote: KG> On Mon, 2007-08-06 at 10:37 +0100, Robert Milkowski wrote: >> Hello Kaiwai, >> >> Saturday, August 4, 2007, 4:13:52 AM, you wrote: >> >> KG> On Fri, 2007-08-03 at 19:42 +0100, Robert Milkowski wrote: >> >> Hello opensolaris-discuss, >> >> >> >> Can anyone shed some light on it? Maybe PSARC materials can be made >> >> publicly available? >> >> >> >> KG> The way I interpete it, it is something like FAM which allows things >> KG> like nautilus to know when something has been change in the file system >> KG> so that it automatically is shown in the file manager window. >> >> I had the same thought still that information should more openly >> available, more in a spirit of open source >> KG> Unfortunately development by Sun isn't occuring in the public, which KG> kinda sucks - someone needs to remind Sun what opensource actually KG> means. Some does some not - we should give them credit for all what has been done so far - it's a huge changeover. I can understand that some projects will be developed 'secretely' and only then integrated - after all Sun is competing in a market. However what is a reasoning for not publishing arc case like in that example with file event notification API? I guess there's none - just old habits... -- Best regards, Robert Milkowski mailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] File Events Notification API - PSARC/2007/027
> On Mon, 2007-08-06 at 03:14 -0700, Doug Scott wrote: > > > On Fri, 2007-08-03 at 19:42 +0100, Robert > Milkowski > > > wrote: > > > > Hello opensolaris-discuss, > > > > > > > > Can anyone shed some light on it? Maybe PSARC > > > materials can be made > > > > publicly available? > > > > > > > > > > The way I interpete it, it is something like FAM > > > which allows things > > > like nautilus to know when something has been > change > > > in the file system > > > so that it automatically is shown in the file > manager > > > window. > > > > Close :) libgaim (FAM clone) can be use by > nautilus/gnome-vfs to > > monitor file/directory updates. The FEN API will be > used by libgamin > > to monitor file events within the kernel. Currently > on Solaris > > libgamin is only able to monitor via polling in > userland. To enable > > this you can build libgamin using SUNWgamin.spec > which currently in > > the spec-files-extra repository on sourceforge. > Once you have > > libgamin, you then need to rebuild SUNWgnome-vfs > and re-login to > > Gnome. (it also works with Xfce). > > > > Doug > > > > > https://pkgbuild.svn.sourceforge.net/svnroot/pkgbuild/ > spec-files-extra/trunk/SUNWgamin.spec > > > https://pkgbuild.svn.sourceforge.net/svnroot/pkgbuild/ > spec-files-extra/trunk/base-specs/gamin.spec > > So I'd assume that with GNOME no longer polling it > should result in > better performance as well. JDS is not linked with gamin at all at the moment. Thats why you have to do a refresh within nautilus to see file changes. Without gamin I think only the desktop is monitored. I originally did the Solaris gamin port for Xfce as you needed to logout and log back in to see things added and removed from the desktop. Currently a Sun Engineer is adding FEN support to gamin. Once it and FEN are completed gamin will be added to JDS. As for performance, from good to bad it probably goes nothing->FEN->polling. Having used both Xfce and Gnome with polling, I can say that the performance hit is very minimal. If you are looking for ways to speed up Gnome. This is not one of them :) Doug This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] File Events Notification API - PSARC/2007/027
On Mon, 2007-08-06 at 03:14 -0700, Doug Scott wrote: > > On Fri, 2007-08-03 at 19:42 +0100, Robert Milkowski > > wrote: > > > Hello opensolaris-discuss, > > > > > > Can anyone shed some light on it? Maybe PSARC > > materials can be made > > > publicly available? > > > > > > > The way I interpete it, it is something like FAM > > which allows things > > like nautilus to know when something has been change > > in the file system > > so that it automatically is shown in the file manager > > window. > > Close :) libgaim (FAM clone) can be use by nautilus/gnome-vfs to > monitor file/directory updates. The FEN API will be used by libgamin > to monitor file events within the kernel. Currently on Solaris > libgamin is only able to monitor via polling in userland. To enable > this you can build libgamin using SUNWgamin.spec which currently in > the spec-files-extra repository on sourceforge. Once you have > libgamin, you then need to rebuild SUNWgnome-vfs and re-login to > Gnome. (it also works with Xfce). > > Doug > > https://pkgbuild.svn.sourceforge.net/svnroot/pkgbuild/spec-files-extra/trunk/SUNWgamin.spec > https://pkgbuild.svn.sourceforge.net/svnroot/pkgbuild/spec-files-extra/trunk/base-specs/gamin.spec So I'd assume that with GNOME no longer polling it should result in better performance as well. Matthew ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] File Events Notification API - PSARC/2007/027
On Mon, 2007-08-06 at 10:37 +0100, Robert Milkowski wrote: > Hello Kaiwai, > > Saturday, August 4, 2007, 4:13:52 AM, you wrote: > > KG> On Fri, 2007-08-03 at 19:42 +0100, Robert Milkowski wrote: > >> Hello opensolaris-discuss, > >> > >> Can anyone shed some light on it? Maybe PSARC materials can be made > >> publicly available? > >> > > KG> The way I interpete it, it is something like FAM which allows things > KG> like nautilus to know when something has been change in the file system > KG> so that it automatically is shown in the file manager window. > > I had the same thought still that information should more openly > available, more in a spirit of open source > Unfortunately development by Sun isn't occuring in the public, which kinda sucks - someone needs to remind Sun what opensource actually means. Matthew ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] File Events Notification API - PSARC/2007/027
> On Fri, 2007-08-03 at 19:42 +0100, Robert Milkowski > wrote: > > Hello opensolaris-discuss, > > > > Can anyone shed some light on it? Maybe PSARC > materials can be made > > publicly available? > > > > The way I interpete it, it is something like FAM > which allows things > like nautilus to know when something has been change > in the file system > so that it automatically is shown in the file manager > window. Close :) libgaim (FAM clone) can be use by nautilus/gnome-vfs to monitor file/directory updates. The FEN API will be used by libgamin to monitor file events within the kernel. Currently on Solaris libgamin is only able to monitor via polling in userland. To enable this you can build libgamin using SUNWgamin.spec which currently in the spec-files-extra repository on sourceforge. Once you have libgamin, you then need to rebuild SUNWgnome-vfs and re-login to Gnome. (it also works with Xfce). Doug https://pkgbuild.svn.sourceforge.net/svnroot/pkgbuild/spec-files-extra/trunk/SUNWgamin.spec https://pkgbuild.svn.sourceforge.net/svnroot/pkgbuild/spec-files-extra/trunk/base-specs/gamin.spec This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] File Events Notification API - PSARC/2007/027
Hello Kaiwai, Saturday, August 4, 2007, 4:13:52 AM, you wrote: KG> On Fri, 2007-08-03 at 19:42 +0100, Robert Milkowski wrote: >> Hello opensolaris-discuss, >> >> Can anyone shed some light on it? Maybe PSARC materials can be made >> publicly available? >> KG> The way I interpete it, it is something like FAM which allows things KG> like nautilus to know when something has been change in the file system KG> so that it automatically is shown in the file manager window. I had the same thought still that information should more openly available, more in a spirit of open source -- Best regards, Robertmailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] File Events Notification API - PSARC/2007/027
On Fri, 2007-08-03 at 19:42 +0100, Robert Milkowski wrote: > Hello opensolaris-discuss, > > Can anyone shed some light on it? Maybe PSARC materials can be made > publicly available? > The way I interpete it, it is something like FAM which allows things like nautilus to know when something has been change in the file system so that it automatically is shown in the file manager window. Matthew ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
