-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kernel notification support #140
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, this looks good overall
@@ -95,6 +98,8 @@ type fileSystemServer struct { | |||
} | |||
|
|||
func (s *fileSystemServer) ServeOps(c *fuse.Connection) { | |||
s.fs.SetConnection(c) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What’s this SetConnection call for? Is it needed? Can you add a comment to the source to explain?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's needed to have something to call Notify() on :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don’t think SetConnection should be added to this interface.
If you want to store a connection field in your FS implementation, that’s fine.
Personally, I would just add a conn: conn,
field to where I construct the &fuseFS{…}
.
But if it doesn’t absolutely need to be in the interface (which I don’t think it does?), it should not be added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should be exported to the user FS code somehow. How to do it?
I mean, the thing that implements interface FileSystem
must be able to call SetConnection() or Notify() on something.
Currently we do
fsint := NewGoofysFuse(fs)
server := fuseutil.NewFileSystemServer(fsint)
fuseMfs, err := fuse.Mount(fs.flags.MountPoint, server, mountCfg)
I think there's an option to add Notify() method to the server
- would it be ok? It will only work when ServeOps(connection)
is active though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I still don’t quite understand.
Can you show me the code that uses this feature? Without an example implementation it’s hard to think this through.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the example. Seeing how the code is used makes me think that we should not pursue the SetConnection
approach. It seems unclean to expose the internal connection and thereby let users call methods in any order (e.g. Connection.Reply, which the doc comment explicitly mentions should not be called).
@jacobsa Would you have a suggestion regarding your preferred way to model this? I’m thinking it would be cleaner to collect kernel notifications and then send them on the connection from an internal function. Perhaps that could also help in preventing the deadlock that is mentioned in the doc comment?
a091e49
to
299578a
Compare
Hi, could you return to this PR and merge it? :-) I have more changes to submit :) |
This PR adds support for notifications from the FUSE server app to the kernel, including:
I tested these in https://github.com/yandex-cloud/geesefs and on Linux these seem to work just fine. Didn't check MacOS because I don't use it, but seems they're also supported there since osxfuse-3.7 https://github.com/osxfuse/osxfuse/releases/tag/osxfuse-3.7.0