Hi,

On 23/12/23 9:27, wirelessduck--- via Dng wrote:

> I forgot to mention shellcheck is available in Devuan/debian repositories and probably for most other distros too.
> I normally run it with --enable=all to get all the optional checks and
> --shell=sh to stick to posix compatibility unless I’m specifically
> needing some bash feature.
> If you want to format your shell scripts for consistency or readability, I can
> suggest`shfmt`. Also available from Devuan/debian repositories as of the
> Daedalus/bookworm release.
> https://github.com/mvdan/sh

Tom, SteveT, Olaf... Thanks a lot for your suggestions!

I continue working on the vdev scripts. Recently, I had a couple of issues related to optical devices.

I've explained them in dev1galaxy:

First, the insertion/removal of dvd drives didn't report any uevent. Surprisingly, `/sys/kernel/uevent_seqnum`
didn't increase automatically along with these events and, therefore, vdev didn't receive any event from netlink
unless the user have typed the `blkid` command afterwards. I've addressed this bug by adding a new vdev action that
sets `/sys/block/sr?/events_poll_msecs` to some number greater than zero (by default -1), which causes the kernel
to poll the device and triggers a uevent when it detects the kernel change without the need of running `blkid` to
increasing the SEQNUM.

I took the idea from eudev/rules/60-block.rules (lines nº 4 - 5) that enables in-kernel media-presence polling:

https://github.com/eudev-project/eudev/blob/master/rules/60-block.rules

The code of the vdev action is as follows:

# main method
# return 0 on success
main() {

   local _EVENTS_POLL_MSECS

   _EVENTS_POLL_MSECS="$VDEV_OS_SYSFS_MOUNTPOINT/$VDEV_OS_DEVPATH/events_poll_msecs"

   if [ "$(/bin/cat $_EVENTS_POLL_MSECS)" -lt 0 ]; then

       /bin/echo 2000 | /usr/bin/tee "$_EVENTS_POLL_MSECS"
   fi

   return 0
}

if [ $VDEV_DAEMONLET -eq 0 ]; then
   main
   exit $?
fi

This new action fixes the first issue with optical devices. However, I still have another issue not fixed yet because xfburn,
k3b and the like don't want to recognize the dvd drive. Arrrr !!

Following on from this is another consideration that you should bear in mind: if you test vdev following the steps explained in
Jude Nelson's `how-to-test.md` -that is, running vdevd on a system with eudev and ensuring that vdevd is creating device nodes
somewhere else besides `/dev`-, then you'll miss details like the aforementioned bug because, under these circumstances, you're
working on top of the already applied udev rules, that may affect the way device information is exported from the kernel space
to the user space by the sysfs filesystem.

Cheers,

Aitor.