On Wed, Nov 17, 2021 at 6:40 PM Verma, Vishal L <[email protected]> wrote: > > On Fri, 2021-09-17 at 11:10 -0700, Dan Williams wrote: > > On Tue, Aug 31, 2021 at 2:05 AM Vishal Verma <[email protected]> > > wrote: > > > > > > Install a helper script that calls daxctl-reconfigure-device with the > > > new 'check-config' option for a given device. This is meant to be called > > > via a systemd service. > > > > > > Install a systemd service that calls the above wrapper script with a > > > daxctl device passed in to it via the environment. > > > > > > Install a udev rule that is triggered for every daxctl device, and > > > triggers the above oneshot systemd service. > > > > > > Together, these three things work such that upon boot, whenever a daxctl > > > device is found, udev triggers a device-specific systemd service called, > > > for example: > > > > > > [email protected] > > > > I'm thinking the service would be called daxdev-add, because it is > > servicing KOBJ_ADD events, or is the convention to name the service > > after what it does vs what it services? > > I don't know of a convention - but 'what it does' seemed more natural > for a service than 'when it's called'. It also correlates better with > usual system service names (i.e. they are named after what they do). > > > > > Also, I'm curious why would "dax0.0" be in the service name, shouldn't > > this be scanning all dax devices and internally matching based on the > > config file? > > Systemd black magic? the dax0.0 doesn't come from anything I configure > - that's just how systemd's 'instantiated services' work. Each newly > added device gets it's own service tied to a unique identifier for the > device. For these, it happens to be /dev/dax0.0, which gets escaped to > -dev-dax0.0. > > More reading here: > http://0pointer.de/blog/projects/instances.html > > > > > > > > > This initiates a daxctl-reconfigure-device with a config lookup for the > > > 'dax0.0' device. If the config has an '[auto-online <unique_id>]' > > > section, it uses the information in that to set the operating mode of > > > the device. > > > > > > If any device is in an unexpected status, 'journalctl' can be used to > > > view the reconfiguration log for that device, for example: > > > > > > journalctl --unit [email protected] > > > > There will be a log per-device, or only if there is a service per > > device? My assumption was that this service is firing off for all > > devices so you would need to filter the log by the device-name if you > > know it... or maybe I'm misunderstanding how this udev service works. > > There will be both a log and a service per device - the unit file we > supply/install is essentially a template for these instantiated > services, but the actual service kicked off is <foo>@<device- > id>.service
Ah, ok, that makes sense.
