Re: skalibs: issue with strnlen() when statically linking with uclibc-ng

[Laurent Bercot]

> Would this difference explains why there is no redefinition linking
> error with musl, or am I missing something?

 I don't know. I will ask people who know. It is strange indeed;
I didn't even notice that the strnlen sysdep was "no" with musl,
else I would have fixed it...



What is the reason for clearing _POSIX_C_SOURCE from trystrnlen.c?


 The set of functions made visible by a libc is generally bigger when
you do *not* define any POSIX or XOPEN macro: systems don't feel like
they have to respect a particular namespace, and export all they have,
or close to all they have. _POSIX_C_SOURCE usually means "only declare
what is strictly POSIX, and if the application is trying to use an
extension, it's an error".

 This is true even for functions actually defined by POSIX, such as
futimens(), the openat() family of functions, and the whole
sys/socket.h family of functions; some (arguably old) libcs mistakenly
fail to expose them when POSIX macros are defined, but expose them
when no such macro is defined. Sometimes they also require a specific
extension macro to expose them. The biggest culprits of this are
Solaris, MacOS, and NetBSD. The only libcs I've never seen stray from
POSIX visibility rules are glibc and musl.

 And so, when testing a function's existence, I usually remove all
POSIX macro definitions, assuming that the visibility will be higher
and the function has a higher chance of being detected - so the
system's function is used instead of the workaround.

 In the case of strnlen, though, it appears that this assumption is
wrong. I just tested without the undefs, and unless I missed something
again, strnlen is correctly detected on all the systems that have it.

 My bad then, it's a bug. The latest git head performs the trystrnlen.c
test without the undefs; please test it. If it works for you, I'll
release a new version of skalibs with the fix.

--
 Laurent

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

[Guillermo]

2018-01-12 23:10 GMT-03:00 Laurent Bercot:
>
>  There are modules for which a /sys/class entry, and an appropriate
> major/minor pair for mdevd to create the device node, only appear when
> the module is loaded, and there's no prior uevent file to trigger
> loading the module: the one I've tested it on is ppp_generic.
> /sys/class/ppp/ppp/uevent only appears once you modprobe ppp_generic, at
> the same time as /sys/dev/char/108:0. So even scanning /sys/class
> does not guarantee you'll get events for all the modules you need.
> It probably has to do with the fact that ppp_generic isn't tied to
> any hardware in particular; whereas in Olivier's instance, I suspect
> the hardware was already visible somewhere under /sys/bus.

I'm leaning towards the same explanation. I don't think the device
manager was ever expected to load *all* needed modules, only the
hardware related ones. After all, systemd also has modules-load.d to
explicitly request loading them:

* https://www.freedesktop.org/software/systemd/man/modules-load.d.html

>  The only explanation I see is that the canonical way of triggering
> uevents changed after landley stopped being involved in sysfs and mdev.
> I think this is likely, since his doc mentions the obsolete (but still
> present) /sys/block hierarchy.

As a side note, /sys/block is duplicated in /sys/class/block, and
caught by the /sys/class/*/* scan. On my computer, disks and disk
partitions, for example, are only found there. I also wondered why
'udevadm trigger' didn't access /sys/block.

>  Anyway, I will change to what udev does; but this is annoying because
> it requires a rearchitecture, so it will take some time.
>
>  With the mdev -s model, it was possible to just read from sysfs,
> synthesize events, and send the synthetic events to a dedicated mdevd
> instance. With the udevadm trigger model, this is not what happens:
> instead of reading from sysfs and synthesizing events, the coldplugger
> actually pokes the kernel, which creates real events; and the netlink
> listener must be up in order to receive and process them.

I'm not sure you'd need to modify this part. The uevent files can
still be read, systemd does try to read IFINDEX, MAJOR and MINOR from
them during enumerator_scan_dir_and_add_devices(), and from what I've
seen, the information you can read from them is pretty much the same
as what you get from events triggered by writing to them. I'll tell
you what, I'm going to try doing both things (using eudev's 'udevadm
monitor' to check the netlink part) and see if I get the same results.

G.