On 12/6/21 22:27, aitor wrote:
I've just pushed the changes to gitea.devuan.dev. Look at the lines
107-112 in worker.cpp [*]. Yes, I'm using inotify :)
This is the link to the gui:
https://gitea.devuan.dev/aitor_czr/hopman/src/branch/master/hopman-1.0/gtkmm
Hi,
On 12/6/21 22:22, Didier Kryn wrote:
I was never able to understand the ABI of libudev, due to the
absence of a manual. I have a great admiration for Jude and you to have
understood it. I will have a look at libudev-monitor.c . Nevertheless,
and whatever the method used (netlink for
Hi Steve,
On 12/6/21 21:29, Steve Litt wrote:
Hi Aitor,
Inotify is the Linux-official way of finding device events. As far as I
know, inotify doesn't care whether you use udev, eudev or vdev, which
in my opinion makes it superior. I'd prefer not to have a Hopman with
all sorts of logic if
Le 12/06/2021 à 20:59, aitor a écrit :
>
> Hi Didier,
>
> On 12/6/21 19:42, Didier Kryn wrote:
>> Hello.
>>
>> My aproach with Hopman was to be totally independant of the
>> hotplugger (udev/eudev/vdev/mdev, even systemd) provided it does the
>> job, which is to create the device special
Hi all,
I think inotify is the best foundation for a usb plugin/plugout
detector. I used it in my early 2015 proof of concept proving that
Poettering's socket activation was overkill and could be accomplished
much less intrusively with inotify.
As far as I know, Hopman's only usage is to mount
aitor said on Sat, 12 Jun 2021 00:46:08 +0200
>Thanks, Steve, it's named Hopman. A project started by Didier Kryn. At
>the beginning my point of view was quite different
>because, on the contrary than Didier's design, i didn't use inotify to
>become aware of any kernel uevent. The reason why
On 12/6/21 13:01, aitor wrote:
This is exactly what i was talking about when saying "... to create
vdev actions for each (ADD|REMOVE|CHANGE) device event". The BIND action
doesn't exist due to the removal of the netlink connection mentioned
above.
Indeed, the README.md file says that eventfs
On 12/6/21 12:47, aitor wrote:
On 12/6/21 12:22, aitor wrote:
Hi again,
On 12/6/21 0:46, aitor wrote:
Now i'm considering as a possible better approach to create vdev
actions for each (ADD|REMOVE|CHANGE)
In the case of eudev, kernel uevents can be listen by "udevadm monitor".
We should
On 12/6/21 12:22, aitor wrote:
Hi again,
On 12/6/21 0:46, aitor wrote:
Now i'm considering as a possible better approach to create vdev
actions for each (ADD|REMOVE|CHANGE)
In the case of eudev, kernel uevents can be listen by "udevadm monitor".
We should distinguish here between two
Hi again,
On 12/6/21 0:46, aitor wrote:
Now i'm considering as a possible better approach to create vdev
actions for each (ADD|REMOVE|CHANGE)
In the case of eudev, kernel uevents can be listen by "udevadm monitor".
Aitor.
___
Dng mailing list
10 matches
Mail list logo
