Le 27/05/2022 à 15:40, Dr. Nikolaus Klepp via Dng a écrit :
Anno domini 2022 Fri, 27 May 15:11:24 +0200
Didier Kryn scripsit:
Le 26/05/2022 à 13:26, k...@aspodata.se a écrit :
The kernel devtmpfs makes dev files come and go, yes, but they
will have some default user, group and permission setting, so
*dev daemons handle that part.
Yes, I forgot this point.
However handling permission and ownership is a simple task.
Couldn't it be done by a script fed by inotifywait ?
'inotifywait -mqe create --format %f /dev | PermissionManager.sh'
An oversimple hotplugger (~:
Once upon a time there was /proc/sys/kernel/hotplug which did this.
Nik
Yes. The legacy Busybox's mdev is working like this:
/proc/sys/kernel/hotplug points to it.
I think you can invoke your script like this. The script just needs
to read some global variables to know if the uevent causes the creation
of a device file and make sure the kernel has created this file before
changing permissions.
There was a disussion years ago in Busybox, about the respective
merits of /proc/sys/kernel/hotplug versus netlink. In the first case,
you have a "fork bomb" at boot time (launching the hotplugger at each
device creation) and possibly unordered activity, and in the second
case, you have the hotplugger always resident in RAM even when it's not
needed, but sequential activity.
DEVTMPFS was invented later, AFAIK because kernel people were
unhappy with what udev was doing. It happens to offer a third triggering
method to manage devices which have a device file: inotify.
Using inotify is simple and sequential, but the process is
permanently in RAM (like all hotpluggers but mdev). I think it is the
simplest method if you deal only with character and block devices. Of
course, the program isn't necessarily a script. I gave the example to
show how easy it is.
-- Didier
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
