Project

General

Profile

Actions

Bug #15025

closed

hald can't anymore receive events with newer glib versions than 2.63.4

Added by Carsten Grzemba about 2 months ago. Updated about 1 month ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
lib - userland libraries
Start date:
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
External Bug:

Description

hald do not not work with newer glib versions than 2.63.4. because there is a change in g_io_channel_read_line which handles the output of the function differently if the string contains null characters. The related glib change is https://gitlab.gnome.org/GNOME/glib/-/issues/2002.
For the Mate Desktop user means this, that USB storage devices are no longer mounted and removed.
The proposed fix will modify the events sent.

The fix changes the events sent so that they can be received by g_io_channel_read_line in the previous (6.62.6) as well as in the new version (eg. 2.70.5) of glib-2.


Related issues

Related to OpenIndiana Distribution - Bug #14226: service/hal needs restart after hardware changeResolved

Actions
Related to illumos gate - Bug #14227: USB automount failure implicates haldResolved

Actions
Actions #1

Updated by Electric Monk about 2 months ago

  • Gerrit CR set to 2404
Actions #2

Updated by Carsten Grzemba about 2 months ago

  • Related to Bug #14226: service/hal needs restart after hardware change added
Actions #3

Updated by Carsten Grzemba about 2 months ago

This openindiana issue #14226 will be fixed with this fix

Actions #5

Updated by Gary Mills about 2 months ago

This is just the change I was looking for. I recommend it.

There is an sscanf() call in hald that processes the line read from the self-pipe. Now that the line is no longer NUL-terminated, will the sscanf function still work properly? Note that the line is still newline-terminated. If it will still work, as I expect, this change is all that we need.

Actions #6

Updated by Gary Mills about 2 months ago

Another bug report that gives more details on this change is: 14227 .

Actions #7

Updated by Marcel Telka about 2 months ago

  • Related to Bug #14227: USB automount failure implicates hald added
Actions #8

Updated by Carsten Grzemba about 2 months ago

I guess you mean this part of code

         while (g_io_channel_read_line(sysevent_iochannel, &s, &len, NULL,
             &err) == G_IO_STATUS_NORMAL) {
                 if (len == 0) {
                         break;
                 }
                 HAL_INFO(("IOChannel val => %s", s));
                 class[0] = subclass[0] = phys_path[0] = dev_name[0] =
                     dev_hid[0] = dev_uid[0] = '\0';
                 matches = sscanf(s, "%s %s %s %s %s %s %d", class, subclass,
                     phys_path, dev_name, dev_hid, dev_uid, &dev_index);
                 g_free(s);
                 s = NULL;
                 if (matches < 3) {
                         continue;
                 }

So at least 3 values are expected here.

I changed the following log command to log all posible values

                HAL_INFO(("sysevent matches=%d: class=%s, sub=%s, phys_path=%s, " 
                     "dev_name=%s, dev_hid=%s, dev_uid=%s, dev_idx=%d",
                     match, class, subclass, phys_path, dev_name, dev_hid, dev_index));

For mount it logs

18:46:07.647 [I] sysevent.c:271: IOChannel val => EC_devfs ESC_devfs_devi_add /pci@0,0/pci1025,574@1d/hub@1/storage@2
18:46:07.647 [I] sysevent.c:283: sysevent matches=3: class=EC_devfs, sub=ESC_devfs_devi_add, phys_path=/pci@0,0/pci1025,574@1d/hub@1/storage@2, dev_name=, dev_hid=, dev_uid=(null), dev_idx=4
18:46:07.647 [I] sysevent.c:456: devfs_handle: /pci@0,0/pci1025,574@1d/hub@1/storage@2
18:46:07.657 [I] sysevent.c:192: sysevent_dev_handler: wrote 77 bytes

for umount

18:46:40.938 [I] sysevent.c:271: IOChannel val => EC_dev_remove disk /pci@0,0/pci1025,574@1d/hub@1/storage@2/disk@0,0 /dev/rdsk/c3t0d0   0
18:46:40.938 [I] sysevent.c:283: sysevent matches=5: class=EC_dev_remove, sub=disk, phys_path=/pci@0,0/pci1025,574@1d/hub@1/storage@2/disk@0,0, dev_name=/dev/rdsk/c3t0d0, dev_hid=0, dev_uid=(null), dev_idx=4
18:46:40.938 [I] sysevent.c:357: dev_remove: /dev/rdsk/c3t0d0 /pci@0,0/pci1025,574@1d/hub@1/storage@2/disk@0,0
18:46:42.012 [I] sysevent.c:241: sysevent_dev_handler: wrote 81 bytes

All the 7 values are only needed for EC_PWRCTL event. If I unplug/plug my power supply from my notebook I see:

18:31:31.663 [I] sysevent.c:271: IOChannel val => EC_pwrctl ESC_pwrctl_state_change /pseudo/acpi_drv@0 noname PNP0C0A 1 0
18:31:31.663 [I] sysevent.c:283: sysevent matches=7: class=EC_pwrctl, sub=ESC_pwrctl_state_change, phys_path=/pseudo/acpi_drv@0, dev_name=noname, dev_hid=PNP0C0A, dev_uid=(null), dev_idx=4
18:31:31.841 [I] sysevent.c:241: sysevent_dev_handler: wrote 72 bytes

So I would say that all possible 7 values was correct readed by sscanf.

Important is that the result is the same for glib-2.62.7 and for glib-2.70.5, so tha change works in both cases with the old glib and the newer with the change function g_io_channel_read_line

Actions #9

Updated by Electric Monk about 1 month ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

git commit e59cb7a82e3c588904c5b7ede8cba0bf3cd17eb1

commit  e59cb7a82e3c588904c5b7ede8cba0bf3cd17eb1
Author: Carsten Grzemba <cgrzemba@opencsw.org>
Date:   2022-10-15T13:54:01.000Z

    15025 hald can't anymore receive events with newer glib versions than 2.63.4
    Reviewed by: Andy Fiddaman <illumos@fiddaman.net>
    Reviewed by: Klaus Ziegler <klausz@haus-gisela.de>
    Reviewed by: Gary Mills <gary_mills@fastmail.fm>
    Reviewed by: Andrew Stormont <andyjstormont@gmail.com>
    Reviewed by: Joshua M. Clulow <josh@sysmgr.org>
    Approved by: Gordon Ross <gordon.w.ross@gmail.com>

Actions

Also available in: Atom PDF