Hello,
in linux kernel is DNOTIFY actually marked as deprecated, with superior
replacement INOTIFY.
Is any plan to migrate rpc.idmapd to INOTIFY? As I looked, it's just one
file.
If there is some on-going porting, I'd like to test/report bugs/send
patches, otherwise I'd like to try port it.
Thank you for answer
David Heidelberger (okias)
On Mon, Mar 10, 2014 at 10:21:02AM +1100, NeilBrown wrote:
> On Fri, 07 Mar 2014 21:30:34 +0100 David Heidelberger
> <[email protected]> wrote:
>
> > Hello,
> >
> > in linux kernel is DNOTIFY actually marked as deprecated, with superior
> > replacement INOTIFY.
>
> Where is it marked as deprecated? I would be very surprised if dnotify
> wasn't supported indefinitely.
Unfortunately, it will be - once it's in, it's in.
> (I have no opinion on whether rpc.idmapd should be changed to use inotify,
> except based on the "if it ain't broke, don't fix it" principle).
I still don't understand WTF does rpc.imapd *want* either of those, TBH.
Said that, the original posting does read a bit like "herpes is so last century,
shouldn't we upgrade to clap by now?"...*0O(and I don't want to think what
that makes fanotify, thank you very much)
Neil, what you think? Should I try someway simplify this as Al proposed?
Dne 2014-03-10 02:45, Al Viro napsal:
> On Mon, Mar 10, 2014 at 11:56:59AM +1100, NeilBrown wrote:
>
>> > I still don't understand WTF does rpc.imapd *want* either of those, TBH.
>>
>> The rpc_pipefs filesysem which is mounted on /var/lib/nfs/rpc_pipefs
>> creates
>> new channels for talking to userspace by making new pipes appear in
>> some
>> directory. Any client needs to arrange some notification for these
>> new pipes
>> appearing so that it can open them and hold a conversation over them.
>> This calls for dnotify (in gssd and idmapd) or inotify (in blkmapd).
>
> ... or just adding ->poll() to the directory in question and using the
> normal syscalls instead of all that weird crap.
On Mon, Mar 10, 2014 at 11:56:59AM +1100, NeilBrown wrote:
> > I still don't understand WTF does rpc.imapd *want* either of those, TBH.
>
> The rpc_pipefs filesysem which is mounted on /var/lib/nfs/rpc_pipefs creates
> new channels for talking to userspace by making new pipes appear in some
> directory. Any client needs to arrange some notification for these new pipes
> appearing so that it can open them and hold a conversation over them.
> This calls for dnotify (in gssd and idmapd) or inotify (in blkmapd).
... or just adding ->poll() to the directory in question and using the
normal syscalls instead of all that weird crap.
On Fri, 07 Mar 2014 21:30:34 +0100 David Heidelberger
<[email protected]> wrote:
> Hello,
>
> in linux kernel is DNOTIFY actually marked as deprecated, with superior
> replacement INOTIFY.
Where is it marked as deprecated? I would be very surprised if dnotify
wasn't supported indefinitely.
(I have no opinion on whether rpc.idmapd should be changed to use inotify,
except based on the "if it ain't broke, don't fix it" principle).
NeilBrown
>
> Is any plan to migrate rpc.idmapd to INOTIFY? As I looked, it's just one
> file.
>
> If there is some on-going porting, I'd like to test/report bugs/send
> patches, otherwise I'd like to try port it.
>
> Thank you for answer
> David Heidelberger (okias)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 10 Mar 2014 00:20:15 +0000 Al Viro <[email protected]> wrote:
> On Mon, Mar 10, 2014 at 10:21:02AM +1100, NeilBrown wrote:
> > On Fri, 07 Mar 2014 21:30:34 +0100 David Heidelberger
> > <[email protected]> wrote:
> >
> > > Hello,
> > >
> > > in linux kernel is DNOTIFY actually marked as deprecated, with superior
> > > replacement INOTIFY.
> >
> > Where is it marked as deprecated? I would be very surprised if dnotify
> > wasn't supported indefinitely.
>
> Unfortunately, it will be - once it's in, it's in.
>
> > (I have no opinion on whether rpc.idmapd should be changed to use inotify,
> > except based on the "if it ain't broke, don't fix it" principle).
>
> I still don't understand WTF does rpc.imapd *want* either of those, TBH.
The rpc_pipefs filesysem which is mounted on /var/lib/nfs/rpc_pipefs creates
new channels for talking to userspace by making new pipes appear in some
directory. Any client needs to arrange some notification for these new pipes
appearing so that it can open them and hold a conversation over them.
This calls for dnotify (in gssd and idmapd) or inotify (in blkmapd).
NeilBrown
>
> Said that, the original posting does read a bit like "herpes is so last century,
> shouldn't we upgrade to clap by now?"...*0O(and I don't want to think what
> that makes fanotify, thank you very much)
Dne 2014-03-10 00:21, NeilBrown napsal:
> On Fri, 07 Mar 2014 21:30:34 +0100 David Heidelberger
> <[email protected]> wrote:
>
>> Hello,
>>
>> in linux kernel is DNOTIFY actually marked as deprecated, with
>> superior
>> replacement INOTIFY.
>
> Where is it marked as deprecated? I would be very surprised if dnotify
> wasn't supported indefinitely.
Dnotify is a directory-based per-fd file change notification system
that uses signals to communicate events to user-space. There exist
superior alternatives, but some applications may still rely on
dnotify.
(fs/notify/dnotify/Kconfig)
In this moment, for modern systems I'm no aware of software actually
using DNOTIFY.
Actually there is choice between INOTIFY and FSNOTIFY.
>
> (I have no opinion on whether rpc.idmapd should be changed to use
> inotify,
> except based on the "if it ain't broke, don't fix it" principle).
Well, I'd like to propose build option which notify system include. It
seems like *notify support reside only in rpc.idmapd, so it shouldn't be
hard.
David
>
> NeilBrown
>
>>
>> Is any plan to migrate rpc.idmapd to INOTIFY? As I looked, it's just
>> one
>> file.
>>
>> If there is some on-going porting, I'd like to test/report bugs/send
>> patches, otherwise I'd like to try port it.
>>
>> Thank you for answer
>> David Heidelberger (okias)
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs"
>> in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 10 Mar 2014 01:55:15 +0100 David Heidelberger
<[email protected]> wrote:
> Dne 2014-03-10 00:21, NeilBrown napsal:
> > On Fri, 07 Mar 2014 21:30:34 +0100 David Heidelberger
> > <[email protected]> wrote:
> >
> >> Hello,
> >>
> >> in linux kernel is DNOTIFY actually marked as deprecated, with
> >> superior
> >> replacement INOTIFY.
> >
> > Where is it marked as deprecated? I would be very surprised if dnotify
> > wasn't supported indefinitely.
>
>
> Dnotify is a directory-based per-fd file change notification system
> that uses signals to communicate events to user-space. There exist
> superior alternatives, but some applications may still rely on
> dnotify.
>
> (fs/notify/dnotify/Kconfig)
The fact that the new alternatives are (supposedly) superior doesn't mean the
old are deprecated.
>
> In this moment, for modern systems I'm no aware of software actually
> using DNOTIFY.
I tend to use DNOTIFY because, much as I hate signals, it actually works with
python while python doesn't know about the new inotify systemcall (though I
know there is now some plug-in thing).
I suspect there is a lot of software that uses DNOTIFY that you don't know
about.
>
> Actually there is choice between INOTIFY and FSNOTIFY.
> >
> > (I have no opinion on whether rpc.idmapd should be changed to use
> > inotify,
> > except based on the "if it ain't broke, don't fix it" principle).
>
> Well, I'd like to propose build option which notify system include. It
> seems like *notify support reside only in rpc.idmapd, so it shouldn't be
> hard.
Feel free to post a patch. You should make it clear how the change actually
benefits nfs-utils. Make sure you don't use the word "deprecated" because
dnotify is *not* deprecated.
Thanks,
NeilBrown
>
> David
> >
> > NeilBrown
> >
> >>
> >> Is any plan to migrate rpc.idmapd to INOTIFY? As I looked, it's just
> >> one
> >> file.
> >>
> >> If there is some on-going porting, I'd like to test/report bugs/send
> >> patches, otherwise I'd like to try port it.
> >>
> >> Thank you for answer
> >> David Heidelberger (okias)
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-nfs"
> >> in
> >> the body of a message to [email protected]
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 12 Mar 2014 23:52:31 +0100 David Heidelberger
<[email protected]> wrote:
> Neil, what you think? Should I try someway simplify this as Al proposed?
No, Al is just letting off steam.
He hates the *notify interfaces (not without reason) and wishes people would
avoid them where-ever possible.
However rpc_pipefs does implement these interfaces, and doesn't implement
'poll' on directories, so changing nfs-utils to use poll wouldn't help.
I really don't think there is any need to do anything. It works and there is
not expectation that it will every stop working, and no evidence that there
is any problem with how it works. So best to leave it alone.
NeilBrown
>
> Dne 2014-03-10 02:45, Al Viro napsal:
> > On Mon, Mar 10, 2014 at 11:56:59AM +1100, NeilBrown wrote:
> >
> >> > I still don't understand WTF does rpc.imapd *want* either of those, TBH.
> >>
> >> The rpc_pipefs filesysem which is mounted on /var/lib/nfs/rpc_pipefs
> >> creates
> >> new channels for talking to userspace by making new pipes appear in
> >> some
> >> directory. Any client needs to arrange some notification for these
> >> new pipes
> >> appearing so that it can open them and hold a conversation over them.
> >> This calls for dnotify (in gssd and idmapd) or inotify (in blkmapd).
> >
> > ... or just adding ->poll() to the directory in question and using the
> > normal syscalls instead of all that weird crap.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html