On Fri, Prakash Sangappa wrote: > Darren Kenny wrote: > >Hi Prakash, > > > >I don't think it's the implementation that bridges between the kernel > >and the user spaces that's important to JDS, and probably most other > >people - it's the ultimate API that people will have to write to, and > >I think from this perspective that sysevents is not what we want - it > >may be part of the implementation of the final API, but it shouldn't > >really be the main API that developers have to write to. At the moment > >there are two projects, both with the same ABI (AFAIK), that are > >prevalent in the Linux developer community: > > > I understand. It is the API. We should be implementing to support some > standard API for > file events notification. Unfortunately there is no standard API nor > what the requirements are. > Hence the discussion is around understanding what requirements are for > such a feature. > > > > * libfam - http://oss.sgi.com/projects/fam/ > > * gamin - http://www.gnome.org/~veillard/gamin/index.html > > > >They are compared (with some bias of course) at: > >http://www.gnome.org/~veillard/gamin/differences.html > > > >It's an API like these that we need, so I think any solution proposed > >(albeit sysevents underneath) should expose one of these APIs to the > >user, if the same people produce this API as those that expose things > >via sysevents, then things should work at their optimal. Whether it's > >the SAME API is up for debate, but what ever we expose should at least > >provide the same functionality. > > > When you say 'sysevents' what are you referring to? > > Support for a commonly used API, can be provided means of a library. > The implementation will provide a native set of interfaces to support > the desired > functionality/requirements, like using the Event ports interfaces. The > library can > use these native interfaces and expose a common API. > > >One think that people have mentioned before as well is the handling of > >distributed file-systems - how do you propose we handle these - this > >is especially important on Solaris given that the majority of our > >customers use NFS for their home directories. From what I understand > >of the File Event Mechanism (FEM) in the kernel, we are using this in > >NFSv4, can this provide us with the ability to see changes to files > >that occur on a NFSv4 filesystem mounted on my desktop, for instance? > > > The proposed solution will not provide file events generated on a > distributed filesystem > from a remote node. But it certainly can provide file events generated > locally on this distributed > filesystem(Ex NFS client side). I don't think the 'FEM' framework in the > kernel, that is > used for the NFSv4 delegation can provide support for events from > remote nodes. > Clearly, this should be transparent to the API. > > It appears that the distributed filesystem implementation should > provide necessary means > to collect such events. I think the responsibility falls squarely on the > distributed file system > implementation. I don't of if there are any distributed file system > implementation which can > do that.
Did my email about the upcoming NFSv4.1 directory delegation feature not make it to the alias? No, I checked, it is there. :-) NFSv4.1 has a notification mechanism and it has its own set of restrictions but NFSv4.1 will allow for a certain set of notifications to be sent to a client that requests them. You should also note that CIFS also has file notfication methods as well. Spencer _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
