Re: Two "intr" related options missing from the latest libfuse.git?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Two "intr" related options missing from the latest libfuse.git?

Enke Chen
Hi, Nikolaus:

Thanks for your reply. Let me clarify:

----
[enkechen@localhost example]$ ./ioctl -d -o intr /tmp/foo
fuse: unknown option(s): `-o intr'
----

The option is no longer accepted. This will break existing applications.

-- Enke

On Nov 14 2016, Enke Chen <[hidden email]> wrote:

> Hi, Folks:
>
> I just noticed that these two options are missing from the latest
> libfuse.git:
>
>         FUSE_LIB_OPT("intr",                  intr, 1),
>         FUSE_LIB_OPT("intr_signal=%d",        intr_signal, 0),
>
> o It would be good to have "intr" on as the default, but I could
> not find where it is set.
>
> o The "intr_signal" is useful for avoiding conflicts. We should
> keep it.

It still exists, it's just no longer included in the default --help
output. This is because the correct value depends on the file system
implementation.

You can still pass the options to fuse_new(), or (preferred) set the
correct values in the struct fuse_config pointer that's passed to your
filesystem's init() handler.


Best,
-Nikolaus

------------------------------------------------------------------------------
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Two "intr" related options missing from the latest libfuse.git?

Nikolaus Rath
On Nov 15 2016, Enke Chen <[hidden email]> wrote:

> Hi, Nikolaus:
>
> Thanks for your reply. Let me clarify:
>
> ----
> [enkechen@localhost example]$ ./ioctl -d -o intr /tmp/foo
> fuse: unknown option(s): `-o intr'
> ----
>
> The option is no longer accepted. This will break existing
> applications.

Yes. FUSE3 breaks backward compatibility. If you really need to be able
to accept an -o intr option, you need to adjust your application.

I'd be curious to hear the use-case for that, though. If your file
systems supports signal interruptions, wouldn't you enable this option
all the time?


Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Two "intr" related options missing from the latest libfuse.git?

Enke Chen
In reply to this post by Enke Chen
Hi, Nikolaus:

The incompatibility seems to require non-trivial changes in an app, and that
will make it difficult to migrate to 3.0 in the future.

Yes, in our application this "-o intr" is enabled all the time in order to
unblock systems calls when a client process is terminating. The signal-based
interrupt sort of works for us today, but there are limitations to what can
be done in a signal handler. A customized interrupt handler would be more
flexible and more robust for certain applications. For example, one can use
"ptherad_cond_signal" to wake up another thread blocked in "pthread_cond_wait".
 

+ /**
+  * For customizing the interrupt handler by an application.
+  *
+  * The default action for FUSE_INTERRUPT is to wake up the blocking
+  * thread using a signal. But in some cases that may not be suitable.
+  * For example, a thread blocked in "pthread_cond_wait" may only be
+  * waken up by "pthread_cond_signal/broadcast" which is not allowed
+  * in a signal handler.
+  *
+  * The funciton is for installing an interrupt handler as well as a
+  * function that returns the data (usually per-thread based) that may
+  * be needed by the interrupt handler.
+
+  * The interrupt handler is used only when the target thread runs
+  * in-between the calls of "fuse_prepare_interrupt" and
+  * "fuse_finish_interrupt".
+  *
+  * If needed, the function should be called once before fuse_main().
+  *
+  * @param handler the interrupt handler that has the target thread-id
+  *        and the data (obtained from "get_data" function) as parameters.
+  *
+  * @param get_data the function that returns the data needed by the
+  *        interrupt handler.
+  */
+ void fuse_set_intr_handler(void (*handler)(pthread_t, void *),
+   void *((*get_data)(void)));

I will send out a patch later.

Thanks. -- Enke

On Nov 15 2016, Enke Chen <[hidden email]> wrote:

> Hi, Nikolaus:
>
> Thanks for your reply. Let me clarify:
>
> ----
> [enkechen@localhost example]$ ./ioctl -d -o intr /tmp/foo
> fuse: unknown option(s): `-o intr'
> ----
>
> The option is no longer accepted. This will break existing
> applications.

Yes. FUSE3 breaks backward compatibility. If you really need to be able
to accept an -o intr option, you need to adjust your application.

I'd be curious to hear the use-case for that, though. If your file
systems supports signal interruptions, wouldn't you enable this option
all the time?


Best,
-Nikolaus

------------------------------------------------------------------------------
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Two "intr" related options missing from the latest libfuse.git?

Nikolaus Rath
On Nov 15 2016, Enke Chen <[hidden email]> wrote:
> Hi, Nikolaus:
>
> The incompatibility seems to require non-trivial changes in an app, and that
> will make it difficult to migrate to 3.0 in the future.

Yes. That's why FUSE 3 has been in the making for quite a long time.

> Yes, in our application this "-o intr" is enabled all the time in order to
> unblock systems calls when a client process is terminating.

Then you should not have a command line option for it, but have the
application enable it internally (that holds for both FUSE 2.x and 3).


Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Two "intr" related options missing from the latest libfuse.git?

Enke Chen
Hi, Nikolaus:

On 11/15/16 2:34 PM, Nikolaus Rath wrote:

> On Nov 15 2016, Enke Chen <[hidden email]> wrote:
>> Hi, Nikolaus:
>>
>> The incompatibility seems to require non-trivial changes in an app, and that
>> will make it difficult to migrate to 3.0 in the future.
>
> Yes. That's why FUSE 3 has been in the making for quite a long time.
>
>> Yes, in our application this "-o intr" is enabled all the time in order to
>> unblock systems calls when a client process is terminating.
>

> Then you should not have a command line option for it, but have the
> application enable it internally (that holds for both FUSE 2.x and 3).

Not sure what you meant by "have the application enable it internally".  Currently
in our application we simply pass several options as the argument to "fuse_main"
without understanding how it works.

Thanks.  -- Enke
 

------------------------------------------------------------------------------
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Two "intr" related options missing from the latest libfuse.git?

Enke Chen
Hi, Nikolaus:

After looking at the examples that use the "init" operations, I now understand
your suggestion about using the "init" operation to set up the "intr" option in
FUSE 3.0. That should work.

Thanks.  -- Enke

On 11/15/16 2:47 PM, Enke Chen wrote:

> Hi, Nikolaus:
>
> On 11/15/16 2:34 PM, Nikolaus Rath wrote:
>> On Nov 15 2016, Enke Chen <[hidden email]> wrote:
>>> Hi, Nikolaus:
>>>
>>> The incompatibility seems to require non-trivial changes in an app, and that
>>> will make it difficult to migrate to 3.0 in the future.
>>
>> Yes. That's why FUSE 3 has been in the making for quite a long time.
>>
>>> Yes, in our application this "-o intr" is enabled all the time in order to
>>> unblock systems calls when a client process is terminating.
>>
>
>> Then you should not have a command line option for it, but have the
>> application enable it internally (that holds for both FUSE 2.x and 3).
>
> Not sure what you meant by "have the application enable it internally".  Currently
> in our application we simply pass several options as the argument to "fuse_main"
> without understanding how it works.
>
> Thanks.  -- Enke
>  
>

------------------------------------------------------------------------------
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Loading...