Re: [DNG] USB mount problem

[aitor]

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 



And, by the bye, the newest libudev-compat:

https://gitea.devuan.dev/aitor_czr/libudev-compat/src/branch/master 



Cheers,

Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] USB mount problem

[aitor]

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 libudev or files for
libudev-compat), it relies on the hotplugger to populate its database. I
don't think this makes a big difference, except that udev make things
more confuse by using the same netlink as the kernel to talk to libudev.

     It seems to me that, with libudev-compat you could have Vdevd create
the symlinks, so that your problem would be solved. Do I understand
well? This seems to me completely independant of Hopman which is desirable.


Yes, you understood well. And i think the problem has been partially 
addressed.


Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] USB mount problem

[aitor]

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 vdev, elsif eudev, else udev, ESPECIALLY if the
device handler decision is made at compile time. Only slightly
better would be to have three Hopmans: One for each device handler.

If there are missing symlinks in /dev/disk, why not fix that root cause
and let the inotify authors worry about different device handlers,
rather than base your program logic on something the systemd people can
change any time, possibly forcing vdev and eudev to change in order to
keep up?

I've used inotify: It's an excellent way to find specific events,
although the filtering of the event stream is somewhat complex. Why not
reconsider using inotify?


Sorry if i've been unclear... I started my first post saying:

"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."

As i explained to Didier a couple of weeks ago, i'm not against the use of 
inotify.
Quite the opposite, i consider it a great tool. But i had problems with the 
mentioned
symlinks in /dev/disk and i took a temporary solution while i was designing the 
gui.
Indeed, the tarball in packages.gnuinos.org contains inotify, but i didn't 
upgrade the git
repository. I've just pushed the changes to gitea.devuan.dev. Look at the lines
107-112 in worker.cpp [*]. Yes, I'm using inotify :)

Cheers,

Aitor.

[*] You'll find the code a mess, i admit, but i'm improving it.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] USB mount problem

[Didier Kryn]

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 file in /dev (which the
>> kernel can do on its own). Then, if the hotplugger is capable to create
>> a symlink in /dev/disk/by-label, then Hopman uses it to display the disk
>> label and eventually passes it to the mount helper. 
> And this is the problem i was having with vdev. The capability to
> create symlinks in /dev/disk in the right way (maybe my fault),
> and this is the reason whyi was using blkid to get the disk label.
>> Hopman is a single-threaded program;
> I'm used to using a worker thread to make it update the gui without
> crashing. Although, I've been using your single-threaded version
> for a long time and it works fine, doing the job.
>>  its only dependencies are the presence of a
>> kernel with the inotify and signalfd APIs, which is the case since more
>> than a decade, unless disabled during kernel build, which would be evil.
>
> "Moreover, the approach of libudev-compat is generic enough to not
> specific to a particular kernel or device manager" -Jude Nelson.
>
> Btw, i'm splitting the content of the vdev project in vdevd and the
> helpers on the one hand, and libudev-compat on the other,increasing
> the version of libudev-compat in the same rate as libeudev for the
> sake of a less painful packaging maintainence:
>
> https://gitea.devuan.dev/aitor_czr/libudev-compat
> 
>
> What do you think about this?
>
> @Didier: if you are interested in how libudev-compat works, give
> special attention to libudev-monitor.c and libudev-fs.c
>
    Hi AItor.

    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 libudev or files for
libudev-compat), it relies on the hotplugger to populate its database. I
don't think this makes a big difference, except that udev make things
more confuse by using the same netlink as the kernel to talk to libudev.

    It seems to me that, with libudev-compat you could have Vdevd create
the symlinks, so that your problem would be solved. Do I understand
well? This seems to me completely independant of Hopman which is desirable.

    Cheers.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Hopman and inotify

[Steve Litt]

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 thumb drives and USB
connected SATA drives. If that's the case, filtering the inotify event
stream should be fairly straightforward. Once detection is
accomplished, functions, callbacks or objects can be used to accomplish
the proper action.

SteveT

Steve Litt 
Spring 2021 featured book: Troubleshooting Techniques of the Successful 
Technologist
http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] USB mount problem

[Steve Litt]

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
>i avoided inotify was related to some missing symlinks in /dev/disk
>when using vdev as device manager (hopman will be
>compatible with both eudev and vdev, and i wanted to use this
>directory as one of the wathdirs for inotify). Now i'm
>considering as a possible better approach to create vdev actions for 
>each (ADD|REMOVE|CHANGE) device events, and their equivalent
>udev rules for eudev to trigger them in a way that hopman only will be 
>notified about changes in the /proc/mounts file
>whenever the user uses pmount or any similar tool -via the gui of 
>hopman- to mount/unmount partitions.

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 vdev, elsif eudev, else udev, ESPECIALLY if the
device handler decision is made at compile time. Only slightly
better would be to have three Hopmans: One for each device handler.

If there are missing symlinks in /dev/disk, why not fix that root cause
and let the inotify authors worry about different device handlers,
rather than base your program logic on something the systemd people can
change any time, possibly forcing vdev and eudev to change in order to
keep up?

I've used inotify: It's an excellent way to find specific events,
although the filtering of the event stream is somewhat complex. Why not
reconsider using inotify?

Thanks,

SteveT

Steve Litt 
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] USB mount problem

[aitor]

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 is currently used to:

 - Give libudev-compat clients a way to receive device events while [ ... ]

Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] USB mount problem

[aitor]

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 distinguish here between two different events:

- The kernel uevent (BIND|ADD|REMOVE|CHANGE)

- The udev event: sent out by udev after the kernel uevent rule processing

Vdev's libudev-compat library removes this netlink connection to udev 
in favor of sending serialized device events by writing them as files.


And..., whops! Here, Jude Nelson says:

" It is highly recommended that users install eventfs

https://github.com/jcnelson/eventfs 

and use it to host libudev-compat's event directories. "

I didn't install it!

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.

Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] USB mount problem

[aitor]

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 different events:

- The kernel uevent (BIND|ADD|REMOVE|CHANGE)

- The udev event: sent out by udev after the kernel uevent rule processing

Vdev's libudev-compat library removes this netlink connection to udev in 
favor of sending serialized device events by writing them as files.


And..., whops! Here, Jude Nelson says:

" It is highly recommended that users install eventfs

https://github.com/jcnelson/eventfs 

and use it to host libudev-compat's event directories. "

I didn't install it!

Aitor.



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] USB mount problem

[aitor]

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
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng