Re: src/cmd.c src/resource.c src/resource.h src/sanlock.8 src/sanlock_internal.h src/sanlock_resource.h

[Federico Simoncelli]

----- Original Message -----
>  From: "David Teigland" <teigland(a)fedoraproject.org&gt;
>  To: sanlock-devel(a)lists.fedorahosted.org
>  Sent: Tuesday, April 9, 2013 9:55:08 PM
>  Subject: src/cmd.c src/resource.c src/resource.h src/sanlock.8	src/sanlock_internal.h
> src/sanlock_resource.h
>  
>  src/cmd.c              |    7 ++++++-
>   src/resource.c         |   35 +++++++++++++++++++++--------------
>   src/resource.h         |    3 ++-
>   src/sanlock.8          |    3 +++
>   src/sanlock_internal.h |    2 ++
>   src/sanlock_resource.h |    2 ++
>   6 files changed, 36 insertions(+), 16 deletions(-)
>  
>  New commits:
>  commit 0ea5e61b9e73459a75ccabfc248359405b2a6b3f
>  Author: David Teigland <teigland(a)redhat.com&gt;
>  Date:   Tue Apr 9 14:41:25 2013 -0500
>  
>      sanlock: add request killpath
>      
>      sanlock_request with force_mode 3 "REQ_KILLPATH"
>      will cause killpath to be run against the pid. 
I have the feeling that this shouldn't be separated from SANLK_REQ_SIGUSR1.
Let's say that the host that submits the request doesn't know if there's a
killpath defined on the target.

I think that there are only two kind of requests:

1. graceful (either with SIGUSR1 or eventually with killpath when it's defined
   on the target)
2. forced (SIGKILL)

Now this means that when one host receives the SANLK_REQ_SIGUSR1 request should
either handle it with killpath or SIGUSR1 (if killpath is not defined).
The SANLK_REQ_SIGUSR1 name might be misleading and therefore I suggest to add a
new macro called SANLK_REQ_GRACEFUL which is exactly == SANLK_REQ_SIGUSR1.
The SANLK_REQ_SIGUSR1 can be obsoleted in the future but for now we should keep
it for backward compatibility.

-- 
Federico