5:52 p.m.
Hi,
Based on the discussions we've had, I've rewritten the bulk of
mdevctl. I think it largely does everything we want now, modulo
devices that will need some sort of 1:N values per key for
configuration in the config file versus the 1:1 key:value setup we
currently have (so don't consider the format final just yet).
We now support "transient" devices and there's no distinction or
difference in handling of such devices whether they're created by
mdevctl or externally. All devices will also have systemd management,
though systemd is no longer required, it's used if available. The
instance name used for systemd device units has also changed to allow
us to use BindsTo= such that services are not only created, but are
also removed if the device is removed. Unfortunately it's not a simple
UUID via the systemd route any longer.
Since the original posting, the project has moved from my personal
github to here:
https://github.com/mdevctl/mdevctl
Please see the README there for overview of the new commands and
example of their usage. There is no attempt to maintain backwards
compatibility with previous versions, this tool is in its infancy.
Also since the original posting, RPM packaging is included, so simply
run 'make rpm' and install the resulting package.
Highlights of this version include proper argument parsing via getopts
so that options can be provided in any order. I'm still using the
format 'mdevctl {command} [options]' but now it's consistent that all
the options come after the command, in any order. I think this is
relatively consistent with a variety of other tools.
Devices are no longer automatically persisted, we handle them as
transient, but we also can promote them to persistent through the
'define' command. The define, undefine, and modify commands all
operate only on the config file, so that we can define separate from
creating. When promoting from a transient to defined device, we can
use the existing device to create the config. Both the type and the
startup of a device can be modified in the config, without affecting
the running device.
Starting an mdev device no longer relies exclusively on a saved config,
the device can be fully specified via options to create a transient
device. Specifying only a uuid is also sufficient for a defined
device. Some consideration has also been given to uuid collisions.
The mdev interface in the kernel prevents multiple mdevs with the same
uuid running concurrently, but mdevctl allows mdevs to be defined with
the same uuid under separate parent devices. Some options therefore
allow both a uuid and parent to be specified and require this if the
uuid alone is ambiguous. Clearly starting two such devices at the same
time will fail and is left to higher level tools to manage, just like
the ability to define more devices than there are available instances on
the host system.
The stop and list commands are largely the same ideas as previous
though the semantics are completely different. Listing running devices
now notes which are defined versus transient. Perhaps it might also be
useful when listing defined devices to note which are running.
The sbin/libexec split of mdevctl has been squashed. There are some
commands in the script that are currently only intended to be used from
udev or systemd, these are simply excluded from the help. It's
possible we may want to promote the start-parent-mdevs command out of
this class, but the rest are specifically systemd helpers.
I'll include the current help test message below for further semantic
details, but please have a look-see, or better yet give it a try.
Thanks,
Alex
PS - I'm looking at adding udev change events when a device registers
or unregisters with the mdev core, which should help us know when to
trigger creation of persistent, auto started devices. That support is
included here with the MDEV_STATE="registered|unregistered" environment
values. Particularly, kvmgt now supports dynamic loading an unloading,
so as long as the enable_gvt=1 option is provided to the i915 driver
mdev support can come and go independent of the parent device. The
change uevents are necessary to trigger on that, so I'd appreciate any
feedback on those as well. Until then, the persistence of mdevctl
really depends on mdev support on the parent device being _completely_
setup prior to processing the udev rules.
# mdevctl
Usage: mdevctl {COMMAND} [options...]
Available commands:
define Define a config for an mdev device. Options:
<-u|--uuid=UUID> [<-p|--parent=PARENT> <-t|--type=TYPE>] [-a|--auto]
If the device specified by the UUID currently exists, parent
and type may be omitted to use the existing values. The auto
option marks the device to start on parent availability.
Running devices are unaffected by this command.
undefine Undefine, or remove a config for an mdev device. Options:
<-u|--uuid=UUID> [-p|--parent=PARENT]
If a UUID exists for multiple parents, all will be removed
unless a parent is specified. Running devices are unaffected
by this command.
modify Modify the config for a defined mdev device. Options:
<-u|--uuid=UUID> [-p|--parent=PARENT] [-t|--type=TYPE] \
[[-a|--auto]|[-m|--manual]]
The parent option further identifies a UUID if it is not
unique, the parent for a device cannot be modified via this
command, undefine and re-define should be used instead. The
mdev type and startup mode can be modified. Running devices
are unaffected by this command.
start Start an mdev device. Options:
<-u|--uuid=UUID> [-p|--parent=PARENT] [-t|--type=TYPE]
If the UUID is previously defined and unique, the UUID is
sufficient to start the device (UUIDs may not collide between
running devices). If a UUID is used in multiple defined
configs, the parent device is necessary to identify the config.
Specifying UUID, PARENT, and TYPE allows devices to be started
regardless of a previously defined config (ie. transient mdevs).
stop Stop an mdev device. Options:
<-u|--uuid=UUID>
list List mdev devices. Options:
[-d|--defined]|[-t|--types]
With no options, information about the currently running mdev
devices is provided. Specifing DEFINED lists the configuration
of defined devices, regardless of their running state.
Specifying TYPES lists the mdev types provided by the currently
registered mdev parent devices on the system.