CC list trimmed, since this just turned into a udev-n00b question :)
On Mon, Aug 10, 2015 at 11:32:45AM -0700, Greg KH wrote:
> On Mon, Aug 10, 2015 at 12:31:20PM -0400, Gabriel L. Somlo wrote:
> > From: "Gabriel Somlo" <somlo@xxxxxxx>
> >
> > Each fw_cfg entry of type "file" has an associated 56-char,
> > nul-terminated ASCII string which represents its name. While
> > the fw_cfg device doesn't itself impose any specific naming
> > convention, QEMU developers have traditionally used path name
> > semantics (i.e. "etc/acpi/rsdp") to descriptively name the
> > various fw_cfg "blobs" passed into the guest.
> >
> > This patch attempts, on a best effort basis, to create a
> > directory hierarchy representing the content of fw_cfg file
> > names, under /sys/firmware/fw_cfg/by_name.
> >
> > Upon successful creation of all directories representing the
> > "dirname" portion of a fw_cfg file, a symlink will be created
> > to represent the "basename", pointing at the appropriate
> > /sys/firmware/fw_cfg/by_select entry. If a file name is not
> > suitable for this procedure (e.g., if its basename or dirname
> > components collide with an already existing dirname component
> > or basename, respectively) the corresponding fw_cfg blob is
> > skipped and will remain available in sysfs only by its selector
> > key value.
>
> Shouldn't all of this be done in userspace with the symlinks and all?
> It seems like you are trying to duplicate the /dev/block/by-name and
> such. Policy decisions like symlinks and naming should be done there,
> in userspace, and not directly in sysfs if at all possible.
I'm trying to give up on creating user-friendly symlinks from within
the kernel module itself, and use udev instead.
To that effect, after "modprobe qemu_fw_cfg" I ran:
udevadm info -a -p /sys/firmware/qemu_fw_cfg/by_key/*
which gave me this:
looking at device '/firmware/qemu_fw_cfg/by_key/32':
KERNEL=="32"
SUBSYSTEM==""
DRIVER==""
ATTR{key}=="32"
ATTR{name}=="etc/boot-fail-wait"
ATTR{size}=="4"
looking at parent device '/firmware/qemu_fw_cfg/by_key':
KERNELS=="by_key"
SUBSYSTEMS==""
DRIVERS==""
looking at parent device '/firmware/qemu_fw_cfg':
KERNELS=="qemu_fw_cfg"
SUBSYSTEMS==""
DRIVERS==""
ATTRS{rev}=="1"
So, in order to create symlinks for each device
(/firmware/qemu_fw_cfg/by_key/32, 33, 34, ...) I *think* something
like this (/lib/udev/rules.d/99-qemu-fw-cfg.rules) should work:
KERNELS="qemu-fw_cfg", ATTRS{rev}==1, SYMLINK="%p/%s{name}"
Except, when I "modprobe -r qemu_fw_cfg; modprobe qemu_fw_cfg",
nothing happens. Should udev automatically create the symlinks
whenever a loading module creates matching sysfs entries, or am I
missing some sort of mechanism to "hook" into the udev daemon ?
Or maybe I'm matching against the wrong elements ?
Any clue as to why this isn't doing what I *think* I'm asking for
would be highly appreciated ! :)
Thanks,
--Gabriel
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
