Could Intel fix that?
-------- Пересылаемое сообщение --------
20.05.2019, 15:18, "Andrei Borzenkov" <arvidjaar(a)gmail.com>:
On Mon, May 20, 2019 at 10:08 AM Mantas Mikulėnas <grawity(a)gmail.com> wrote:
On Sun, May 19, 2019 at 9:50 PM Alex Ivanov <gnidorah(a)ya.ru>
> What is the proper way to do that? I have a unit that creates gvt device in the
> ExecStart = "sh -c 'echo a297db4a-f4c2-11e6-90f6-d3b88d6c9525 >
> ExecStop = "sh -c 'echo 1 >
Personally, I would use an udev rule:
There is a race condition here, driver creates
.../mdev_supported_types after it has registered device so udev may
process event before directory is available.
Though on the other hand, a service is a good choice if you want to
`systemctl stop` it later on.
> Ideally I would to like to start this service when 0000:00:02.0 device appears in
the system, but the problem is that
/sys/bus/pci/devices/0000:00:02.0/mdev_supported_types/ tree is populated later, so my
service will fail.
> So the question what is the proper way to fix that.
If the driver doesn't populate its sysfs entries in time, maybe it at least
generates 'change' uevents? (udevadm --monitor)
I would tentatively say this is driver bug. This directory is created
during initial device setup, not in response to some event later. From
As explained in Documentation/kobject.txt, device attributes must be
created before the KOBJ_ADD uevent is generated.
Note that some drivers even disable KOBJ_ADD notification during
device_register() and trigger it manually later, after sysfs layout is
complete. I cannot evaluate whether this directory can be created and
populated before device_register().
If there are no uevents either, well, there's nothing you can do
from systemd's side. (Other than making a script that loops repeatedly checking
"is it there yet? is it there yet?")
Should really be fixed on kernel side.
-------- Конец пересылаемого сообщения --------