From: Jeff I. R. <jef...@gm...> - 2008-01-19 14:18:49
|
On 18 =CE=99=CE=B1=CE=BD 2008, at 10:35 =CE=A0=CE=9C, Klas Lindberg = wrote: > Luis, > > Thank you for clearing this up. You are right that the names of > functions is the small problem. Invocation of the functions is the big > issue. I see two ways to go about this: > > 1: If the function does not accept parameters, then it can be > represented as a readable file. When the file is read, the function is > called to produce output. I'm afraid that you are still not done :) Depending on the function's output size, FUSE may call read() more than once, meaning that you function should not have any side-effects, or you should use some form of caching. Even worse, getattr() needs to call your function in order to report the size of the file. And getattr will be called for every action concerning the file, even if you do an ls in the directory. > 2: If the function takes parameters, then it cannot be handled as in > (1), because the parameters passed on the command line will not be > passed with the read() operation to FUSE. To deal with this, I would > create a small binary that inspects $CWD, argv[0] and possibly other > details to figure out which function to call. I'll then use FUSE to > publish a soft link to that binary instead of the readable file. This seems a more feasible solution. You don't even need to return a symlink. You can have the whole executable in memory and return its contents on read(). > What do you think? Would it be a workable solution? Is there some > better way? Would it make sense, for instance, to represent the > function as a writable file and insist that any read() is preceded by > a write() that contains the parameters? You can't emulate a file that is both readable and writable in FUSE (at least not with the high-level interface) |