Re: [PATCH 3/3] firmware: fw_cfg: create directory hierarchy for fw_cfg file names

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux