From: gregkh@linuxfoundation.org (Greg KH)
To: kernelnewbies@lists.kernelnewbies.org
Subject: [PATCH 1/3] firmware: introduce sysfs driver for QEMU's fw_cfg device
Date: Mon, 10 Aug 2015 12:15:09 -0700 [thread overview]
Message-ID: <20150810191509.GA7264@kroah.com> (raw)
In-Reply-To: <20150810190222.GN31816@HEDWIG.INI.CMU.EDU>
On Mon, Aug 10, 2015 at 03:02:22PM -0400, Gabriel L. Somlo wrote:
> Mainly, qemu's fw_cfg is a read-only "device", so one wouldn't ever
> care to try writing anything to it. /sys/firmware/... feels like a fit
> because fw_cfg contains binary blobs originally meant to be used by
> the bios (it's how SeaBIOS and OVMF pull smbios and acpi tables out of
> the host and set them up in guest memory before booting the guest kernel,
> as one of the many examples).
>
> The most similar example (and the existing driver I used as an example
> during implementation) is dmi-sysfs.c, which also exposes all the
> metadata for each smbios table as numeric (or string) read-only attributes,
> and has a "raw" attribute which allows dumping each table in its
> entirety. Same thing here -- I want to expose the name, size, and
> select key for each blob, but also allow access to the "payload", i.e.
> the blob itself.
That's great, and you can have these "blobs" be an attribute for a
struct device. Just using a "raw" kobject as you are is hard, as you
have seen, and messy. Making it a "real" device makes this all much
easier and simpler.
Now if you want to keep things in /sys/firmware/ that's another issue,
and would have to stay as a kobject. so maybe it does need to remain,
need to think about that...
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
To: "Gabriel L. Somlo" <somlo-D+Gtc/HYRWM@public.gmane.org>
Cc: ralf-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org,
zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org,
galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org,
lersek-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
jordan.l.justen-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
gleb-RmZWMc9puTNJc61us3aD9laTQe2KTcn/@public.gmane.org,
pbonzini-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
kraxel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
eblake-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
rjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
kernelnewbies-7JyXY6prKcjpASu1u0TL5ti2O/JbrIOy@public.gmane.org
Subject: Re: [PATCH 1/3] firmware: introduce sysfs driver for QEMU's fw_cfg device
Date: Mon, 10 Aug 2015 12:15:09 -0700 [thread overview]
Message-ID: <20150810191509.GA7264@kroah.com> (raw)
In-Reply-To: <20150810190222.GN31816-h65ZQ0r4j6KKUezXOiBB2eW1CriLhL8O@public.gmane.org>
On Mon, Aug 10, 2015 at 03:02:22PM -0400, Gabriel L. Somlo wrote:
> Mainly, qemu's fw_cfg is a read-only "device", so one wouldn't ever
> care to try writing anything to it. /sys/firmware/... feels like a fit
> because fw_cfg contains binary blobs originally meant to be used by
> the bios (it's how SeaBIOS and OVMF pull smbios and acpi tables out of
> the host and set them up in guest memory before booting the guest kernel,
> as one of the many examples).
>
> The most similar example (and the existing driver I used as an example
> during implementation) is dmi-sysfs.c, which also exposes all the
> metadata for each smbios table as numeric (or string) read-only attributes,
> and has a "raw" attribute which allows dumping each table in its
> entirety. Same thing here -- I want to expose the name, size, and
> select key for each blob, but also allow access to the "payload", i.e.
> the blob itself.
That's great, and you can have these "blobs" be an attribute for a
struct device. Just using a "raw" kobject as you are is hard, as you
have seen, and messy. Making it a "real" device makes this all much
easier and simpler.
Now if you want to keep things in /sys/firmware/ that's another issue,
and would have to stay as a kobject. so maybe it does need to remain,
need to think about that...
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: "Gabriel L. Somlo" <somlo@cmu.edu>
Cc: ralf@linux-mips.org, zajec5@gmail.com, paul@pwsan.com,
galak@codeaurora.org, linux-api@vger.kernel.org,
linux-kernel@vger.kernel.org, matt.fleming@intel.com,
x86@kernel.org, linux-efi@vger.kernel.org, qemu-devel@nongnu.org,
lersek@redhat.com, jordan.l.justen@intel.com,
gleb@cloudius-systems.com, pbonzini@redhat.com,
kraxel@redhat.com, eblake@redhat.com, rjones@redhat.com,
kernelnewbies@kernelnewbies.org
Subject: Re: [PATCH 1/3] firmware: introduce sysfs driver for QEMU's fw_cfg device
Date: Mon, 10 Aug 2015 12:15:09 -0700 [thread overview]
Message-ID: <20150810191509.GA7264@kroah.com> (raw)
In-Reply-To: <20150810190222.GN31816@HEDWIG.INI.CMU.EDU>
On Mon, Aug 10, 2015 at 03:02:22PM -0400, Gabriel L. Somlo wrote:
> Mainly, qemu's fw_cfg is a read-only "device", so one wouldn't ever
> care to try writing anything to it. /sys/firmware/... feels like a fit
> because fw_cfg contains binary blobs originally meant to be used by
> the bios (it's how SeaBIOS and OVMF pull smbios and acpi tables out of
> the host and set them up in guest memory before booting the guest kernel,
> as one of the many examples).
>
> The most similar example (and the existing driver I used as an example
> during implementation) is dmi-sysfs.c, which also exposes all the
> metadata for each smbios table as numeric (or string) read-only attributes,
> and has a "raw" attribute which allows dumping each table in its
> entirety. Same thing here -- I want to expose the name, size, and
> select key for each blob, but also allow access to the "payload", i.e.
> the blob itself.
That's great, and you can have these "blobs" be an attribute for a
struct device. Just using a "raw" kobject as you are is hard, as you
have seen, and messy. Making it a "real" device makes this all much
easier and simpler.
Now if you want to keep things in /sys/firmware/ that's another issue,
and would have to stay as a kobject. so maybe it does need to remain,
need to think about that...
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: "Gabriel L. Somlo" <somlo@cmu.edu>
Cc: x86@kernel.org, paul@pwsan.com, matt.fleming@intel.com,
gleb@cloudius-systems.com, jordan.l.justen@intel.com,
rjones@redhat.com, linux-api@vger.kernel.org, zajec5@gmail.com,
linux-kernel@vger.kernel.org, qemu-devel@nongnu.org,
linux-efi@vger.kernel.org, kernelnewbies@kernelnewbies.org,
kraxel@redhat.com, galak@codeaurora.org, pbonzini@redhat.com,
lersek@redhat.com
Subject: Re: [Qemu-devel] [PATCH 1/3] firmware: introduce sysfs driver for QEMU's fw_cfg device
Date: Mon, 10 Aug 2015 12:15:09 -0700 [thread overview]
Message-ID: <20150810191509.GA7264@kroah.com> (raw)
In-Reply-To: <20150810190222.GN31816@HEDWIG.INI.CMU.EDU>
On Mon, Aug 10, 2015 at 03:02:22PM -0400, Gabriel L. Somlo wrote:
> Mainly, qemu's fw_cfg is a read-only "device", so one wouldn't ever
> care to try writing anything to it. /sys/firmware/... feels like a fit
> because fw_cfg contains binary blobs originally meant to be used by
> the bios (it's how SeaBIOS and OVMF pull smbios and acpi tables out of
> the host and set them up in guest memory before booting the guest kernel,
> as one of the many examples).
>
> The most similar example (and the existing driver I used as an example
> during implementation) is dmi-sysfs.c, which also exposes all the
> metadata for each smbios table as numeric (or string) read-only attributes,
> and has a "raw" attribute which allows dumping each table in its
> entirety. Same thing here -- I want to expose the name, size, and
> select key for each blob, but also allow access to the "payload", i.e.
> the blob itself.
That's great, and you can have these "blobs" be an attribute for a
struct device. Just using a "raw" kobject as you are is hard, as you
have seen, and messy. Making it a "real" device makes this all much
easier and simpler.
Now if you want to keep things in /sys/firmware/ that's another issue,
and would have to stay as a kobject. so maybe it does need to remain,
need to think about that...
thanks,
greg k-h
next prev parent reply other threads:[~2015-08-10 19:15 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-10 16:31 [PATCH 0/3] SysFS driver for QEMU firmware config device (fw_cfg) Gabriel L. Somlo
2015-08-10 16:31 ` [Qemu-devel] " Gabriel L. Somlo
2015-08-10 16:31 ` Gabriel L. Somlo
2015-08-10 16:31 ` Gabriel L. Somlo
2015-08-10 16:31 ` [PATCH 1/3] firmware: introduce sysfs driver for QEMU's fw_cfg device Gabriel L. Somlo
2015-08-10 16:31 ` [Qemu-devel] " Gabriel L. Somlo
2015-08-10 16:31 ` Gabriel L. Somlo
2015-08-10 16:31 ` Gabriel L. Somlo
2015-08-10 18:30 ` Greg KH
2015-08-10 18:30 ` [Qemu-devel] " Greg KH
2015-08-10 18:30 ` Greg KH
2015-08-10 18:30 ` Greg KH
2015-08-10 19:02 ` Gabriel L. Somlo
2015-08-10 19:02 ` [Qemu-devel] " Gabriel L. Somlo
2015-08-10 19:02 ` Gabriel L. Somlo
2015-08-10 19:02 ` Gabriel L. Somlo
2015-08-10 19:15 ` Greg KH [this message]
2015-08-10 19:15 ` [Qemu-devel] " Greg KH
2015-08-10 19:15 ` Greg KH
2015-08-10 19:15 ` Greg KH
2015-08-10 16:31 ` [PATCH 2/3] kobject: export kset_find_obj() to be used from modules Gabriel L. Somlo
2015-08-10 16:31 ` [Qemu-devel] " Gabriel L. Somlo
2015-08-10 16:31 ` Gabriel L. Somlo
2015-08-10 16:31 ` Gabriel L. Somlo
2015-08-10 18:33 ` Greg KH
2015-08-10 18:33 ` [Qemu-devel] " Greg KH
2015-08-10 18:33 ` Greg KH
2015-08-10 18:43 ` Gabriel L. Somlo
2015-08-10 18:43 ` [Qemu-devel] " Gabriel L. Somlo
2015-08-10 18:43 ` Gabriel L. Somlo
2015-08-10 18:43 ` Gabriel L. Somlo
2015-08-10 18:54 ` Greg KH
2015-08-10 18:54 ` [Qemu-devel] " Greg KH
2015-08-10 18:54 ` Greg KH
2015-08-10 18:54 ` Greg KH
2015-08-10 19:04 ` Gabriel L. Somlo
2015-08-10 19:04 ` [Qemu-devel] " Gabriel L. Somlo
2015-08-10 19:04 ` Gabriel L. Somlo
2015-08-10 19:04 ` Gabriel L. Somlo
2015-08-10 16:31 ` [PATCH 3/3] firmware: fw_cfg: create directory hierarchy for fw_cfg file names Gabriel L. Somlo
2015-08-10 16:31 ` [Qemu-devel] " Gabriel L. Somlo
2015-08-10 16:31 ` Gabriel L. Somlo
2015-08-10 16:31 ` Gabriel L. Somlo
2015-08-10 18:32 ` Greg KH
2015-08-10 18:32 ` [Qemu-devel] " Greg KH
2015-08-10 18:32 ` Greg KH
2015-08-10 18:32 ` Greg KH
2015-08-27 19:38 ` Gabriel L. Somlo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150810191509.GA7264@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=kernelnewbies@lists.kernelnewbies.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.