Re: [-next PATCH 4/4] treewide: Use DEVICE_ATTR_WO

[Zhang Rui]

On Tue, 2017-12-19 at 10:15 -0800, Joe Perches wrote:
> Convert DEVICE_ATTR uses to DEVICE_ATTR_WO where possible.
> 
> Done with perl script:
> 
> $ git grep -w --name-only DEVICE_ATTR | \
>   xargs perl -i -e 'local $/; while (<>) {
> s/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,\s*\(?(?:\s*S_IWUSR\s*|\s*0200\s*)\)?
> \s*,\s*NULL\s*,\s*\s_store\s*\)/DEVICE_ATTR_WO(\1)/g; print;}'
> 
> Signed-off-by: Joe Perches <j...@perches.com>
> ---
>  arch/s390/kernel/smp.c | 2 +-
>  arch/x86/kernel/cpu/microcode/core.c   | 2 +-
>  drivers/input/touchscreen/elants_i2c.c | 2 +-
>  drivers/net/ethernet/ibm/ibmvnic.c | 2 +-
>  drivers/net/wimax/i2400m/sysfs.c   | 3 +--
>  drivers/scsi/lpfc/lpfc_attr.c  | 3 +--
>  drivers/thermal/thermal_sysfs.c| 2 +-

For the thermal part,
Acked-by: Zhang Rui <rui.zh...@intel.com>

thanks,
rui

>  7 files changed, 7 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/s390/kernel/smp.c b/arch/s390/kernel/smp.c
> index b8c1a85bcf2d..a919b2f0141d 100644
> --- a/arch/s390/kernel/smp.c
> +++ b/arch/s390/kernel/smp.c
> @@ -1151,7 +1151,7 @@ static ssize_t __ref rescan_store(struct device
> *dev,
>   rc = smp_rescan_cpus();
>   return rc ? rc : count;
>  }
> -static DEVICE_ATTR(rescan, 0200, NULL, rescan_store);
> +static DEVICE_ATTR_WO(rescan);
>  #endif /* CONFIG_HOTPLUG_CPU */
>  
>  static int __init s390_smp_init(void)
> diff --git a/arch/x86/kernel/cpu/microcode/core.c
> b/arch/x86/kernel/cpu/microcode/core.c
> index c4fa4a85d4cb..09c74b0560dd 100644
> --- a/arch/x86/kernel/cpu/microcode/core.c
> +++ b/arch/x86/kernel/cpu/microcode/core.c
> @@ -560,7 +560,7 @@ static ssize_t pf_show(struct device *dev,
>   return sprintf(buf, "0x%x\n", uci->cpu_sig.pf);
>  }
>  
> -static DEVICE_ATTR(reload, 0200, NULL, reload_store);
> +static DEVICE_ATTR_WO(reload);
>  static DEVICE_ATTR(version, 0400, version_show, NULL);
>  static DEVICE_ATTR(processor_flags, 0400, pf_show, NULL);
>  
> diff --git a/drivers/input/touchscreen/elants_i2c.c
> b/drivers/input/touchscreen/elants_i2c.c
> index a458e5ec9e41..819213e88f32 100644
> --- a/drivers/input/touchscreen/elants_i2c.c
> +++ b/drivers/input/touchscreen/elants_i2c.c
> @@ -1000,7 +1000,7 @@ static ssize_t show_iap_mode(struct device
> *dev,
>   "Normal" : "Recovery");
>  }
>  
> -static DEVICE_ATTR(calibrate, S_IWUSR, NULL, calibrate_store);
> +static DEVICE_ATTR_WO(calibrate);
>  static DEVICE_ATTR(iap_mode, S_IRUGO, show_iap_mode, NULL);
>  static DEVICE_ATTR(update_fw, S_IWUSR, NULL, write_update_fw);
>  
> diff --git a/drivers/net/ethernet/ibm/ibmvnic.c
> b/drivers/net/ethernet/ibm/ibmvnic.c
> index 1dc4aef37d3a..42b96e1a1b13 100644
> --- a/drivers/net/ethernet/ibm/ibmvnic.c
> +++ b/drivers/net/ethernet/ibm/ibmvnic.c
> @@ -4411,7 +4411,7 @@ static ssize_t failover_store(struct device
> *dev, struct device_attribute *attr,
>   return count;
>  }
>  
> -static DEVICE_ATTR(failover, 0200, NULL, failover_store);
> +static DEVICE_ATTR_WO(failover);
>  
>  static unsigned long ibmvnic_get_desired_dma(struct vio_dev *vdev)
>  {
> diff --git a/drivers/net/wimax/i2400m/sysfs.c
> b/drivers/net/wimax/i2400m/sysfs.c
> index 1237109f251a..8c67df11105c 100644
> --- a/drivers/net/wimax/i2400m/sysfs.c
> +++ b/drivers/net/wimax/i2400m/sysfs.c
> @@ -65,8 +65,7 @@ ssize_t i2400m_idle_timeout_store(struct device
> *dev,
>  }
>  
>  static
> -DEVICE_ATTR(i2400m_idle_timeout, S_IWUSR,
> - NULL, i2400m_idle_timeout_store);
> +DEVICE_ATTR_WO(i2400m_idle_timeout);
>  
>  static
>  struct attribute *i2400m_dev_attrs[] = {
> diff --git a/drivers/scsi/lpfc/lpfc_attr.c
> b/drivers/scsi/lpfc/lpfc_attr.c
> index 517ff203cfde..6ddaf51a23f6 100644
> --- a/drivers/scsi/lpfc/lpfc_attr.c
> +++ b/drivers/scsi/lpfc/lpfc_attr.c
> @@ -2418,8 +2418,7 @@ lpfc_soft_wwn_enable_store(struct device *dev,
> struct device_attribute *attr,
>  
>   return count;
>  }
> -static DEVICE_ATTR(lpfc_soft_wwn_enable, S_IWUSR, NULL,
> -    lpfc_soft_wwn_enable_store);
> +static DEVICE_ATTR_WO(lpfc_soft_wwn_enable);
>  
>  /**
>   * lpfc_soft_wwpn_show - Return the cfg soft ww port name of the
> adapter
> diff --git a/drivers/thermal/thermal_sysfs.c
> b/drivers/thermal/thermal_sysfs.c
> index 2bc964392924..ba81c9080f6e 100644
> --- a/drivers/thermal/thermal_sysfs.c
> +++ b/drivers/thermal/thermal_sysfs.c
> @@ -317,7 +317,7 @@ emul_temp_store(struct device *dev, struct
> device_attribute *attr,
>  
>   return ret ? ret : count;
>  }
> -static DEVICE_ATTR(emul_temp, S_IWUSR, NULL, emul_temp_store);
> +static DEVICE_ATTR_WO(emul_temp);
>  #endif
>  
>  static ssize_t

Re: CONFIG_DEBUG_INFO_SPLIT impacts on faddr2line

[Zhang Rui]

On Mon, 2017-11-13 at 09:13 +0800, Fengguang Wu wrote:
> CC Andi and more DEBUG_INFO_SPLIT people.
> 
> On Sun, Nov 12, 2017 at 11:31:56AM -0800, Linus Torvalds wrote:
> > 
> > On Wed, Nov 8, 2017 at 9:12 AM, Fengguang Wu  > m> wrote:
> > > 
> > > 
> > > OK. Here is the original faddr2line output:
> > > 
> > > $ ~/linux/scripts/faddr2line vmlinux
> > > vlan_device_event+0x7f5/0xa40
> > > vlan_device_event+0x7f5/0xa40:
> > > vlan_device_event at net/8021q/vlan.h:60
> > > 
> > > And below is call trace embedded with full faddr2line output.
> > > 
> > > I notice that this trace shows no additional inline files at all.
> > > Is it because I did some kconfig option wrong, so that inline
> > > info is
> > > lost? Eg.
> > > 
> > > CONFIG_OPTIMIZE_INLINING=y (it looks better set to N)
> > > CONFIG_DEBUG_INFO_REDUCED=y
> > > CONFIG_DEBUG_INFO_SPLIT=y
> > Ok, this annoyed me, so I went back and looked.
> > 
> > It's the "CONFIG_DEBUG_INFO_SPLIT" thing that makes faddr2line
> > unable
> > to see the inlining information,
> > 
> > Using OPTIMIZE_INLINING is fine.
> Good to know that!
> 
> > 
> > I'm not sure that addr2line could be made to understand the .dwo
> > files
> > that DEBUG_INFO_SPLIT causes (particularly since we munge the
> > vmlinux
> > file itself, who knows how that could confuse things).
> > 
> > So can I ask that you make the 0day build scripts always use
> > 
> >  CONFIG_DEBUG_INFO=y
> >  CONFIG_DEBUG_INFO_REDUCED=y
> >  # CONFIG_DEBUG_INFO_SPLIT is not set
> > 
> > because with that "DEBUG_INFO_REDUCED=y", the use of
> > DEBUG_INFO_SPLIT
> > shouldn't be _that_ big of a deal.
> > 
> > Yes, splitting the debug info does help reduce disk usage for the
> > build, and presumably speed it up a bit too due to less IO and
> > reduced
> > copying of the debug info data, but right now it really makes the
> > debug info much less useful.
> Yes DEBUG_INFO_SPLIT helps reduce build cost. Equally importantly,
> it helps cut down the *.ko sizes, which saves boot test cost, too.
> Since in our test scheme, the below modules.cgz will be loaded as
> part
> of initrd on boot testing. Which will cost memory, and to the lesser
> degree, IO and uncompressing time.
> 
> Here is the diff of the modules.cgz size:
> 
> Big files under /pkg/linux/x86_64-rhel-
> 7.2+CONFIG_DEBUG_INFO_REDUCED/gcc-6/v4.14-rc7/,
> comparing to +CONFIG_DEBUG_INFO_SPLIT:
> 
> =>54M  135M  modules.cgz
>  7.3M  7.3M  vmlinuz-4.14.0-rc7
>  1.2M  1.2M  linux-headers.cgz
>  7.6M  7.7M  linux-selftests.cgz
>   31M   31M  linux-perf.cgz
> 
> Nevertheless, that's machine cost. If DEBUG_INFO_SPLIT hurts our
> ability to analyze bugs, I think the forthright way would be to
> disable it in our tests.
> 
> > 
> > Just to see the difference:
> > 
> > - with DEBUG_INFO_SPLIT=y
> > 
> >    [torvalds@i7 linux]$ ./scripts/faddr2line vmlinux
> > __schedule+0x314
> >    __schedule+0x314/0x840:
> >    __schedule at kernel/sched/stats.h:12
> > 
> > - with DEBUG_INFO_SPLIT is not set
> > 
> >    [torvalds@i7 linux]$ ./scripts/faddr2line vmlinux
> > __schedule+0x314
> >    __schedule+0x314/0x840:
> >    rq_sched_info_arrive at kernel/sched/stats.h:12
> > (inlined by) sched_info_arrive at kernel/sched/stats.h:99
> > (inlined by) __sched_info_switch at kernel/sched/stats.h:151
> > (inlined by) sched_info_switch at kernel/sched/stats.h:158
> > (inlined by) prepare_task_switch at kernel/sched/core.c:2582
> > (inlined by) context_switch at kernel/sched/core.c:2755
> > (inlined by) __schedule at kernel/sched/core.c:3366
> > 
> > and while (once again) this is a pretty extreme case, we do use a
> > lot
> > of inlines, and gcc will add its own inlining. Getting this whole
> > information - particularly for the faulting IP - would really help
> > in
> > some situations.
> > 
> > I love what the 0day robot is doing, this would be another big step
> > forward.
> Thank you for the helpful information and appreciations!
> I'll make the change to disable DEBUG_INFO_SPLIT.
> 
> > 
> > Oh - and talking about "big step forward" - does the 0day robot do
> > any
> > suspend/resume testing at all?
> Yes, we do. CC Rui and Aaron on power testing.
> 
yes, we have added suspend/resume test in 0day, including both
functionality and suspend/resume performance. It is not widely run
because most of the 0Day testboxes are servers/desktops, now we've just
added some client laptops as testboxes, and will add more in the near
future. :)
> > 
> > Even on non-laptop hardware, it should be possible to do something
> > like
> > 
> >    echo platform > /sys/power/pm_test
> >    echo freeze > /sys/power/state
> > 
> > or similar (assuming CONFIG_PM_DEBUG is enabled).
> > 

yes.

I will run native suspend/resume test on laptops and other test boxes
that really support it, and run suspend/resume test in pm_test modes on
the others to help us find more issues.

thanks,
rui
> > Maybe you already do something like this?
> Rui/Aaron have better 

Re: [PATCH v1] ACPI: Switch to use generic UUID API

[Zhang Rui]

On Thu, 2017-05-04 at 12:21 +0300, Andy Shevchenko wrote:
> acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
> bytes. Instead we convert them to use uuid_le type. At the same time
> we
> convert current users.
> 
> acpi_str_to_uuid() becomes useless after the conversion and it's safe
> to
> get rid of it.
> 
> The conversion fixes a potential bug in int340x_thermal as well since
> we have to use memcmp() on binary data.
> 
> Cc: Rafael J. Wysocki <r...@rjwysocki.net>
> Cc: Mika Westerberg <mika.westerb...@linux.intel.com>
> Cc: Borislav Petkov <b...@suse.de>
> Cc: Dan Williams <dan.j.willi...@intel.com>
> Cc: Amir Goldstein <amir7...@gmail.com>
> Cc: Jarkko Sakkinen <jarkko.sakki...@linux.intel.com>
> Cc: Jani Nikula <jani.nik...@linux.intel.com>
> Cc: Ben Skeggs <bske...@redhat.com>
> Cc: Benjamin Tissoires <benjamin.tissoi...@redhat.com>
> Cc: Joerg Roedel <j...@8bytes.org>
> Cc: Adrian Hunter <adrian.hun...@intel.com>
> Cc: Yisen Zhuang <yisen.zhu...@huawei.com>
> Cc: Bjorn Helgaas <bhelg...@google.com>
> Cc: Zhang Rui <rui.zh...@intel.com>
> Cc: Felipe Balbi <ba...@kernel.org>
> Cc: Mathias Nyman <mathias.ny...@intel.com>
> Cc: Heikki Krogerus <heikki.kroge...@linux.intel.com>
> Cc: Liam Girdwood <lgirdw...@gmail.com>
> Cc: Mark Brown <broo...@kernel.org>
> Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
> ---
> 
> diff --git a/drivers/thermal/int340x_thermal/int3400_thermal.c
> b/drivers/thermal/int340x_thermal/int3400_thermal.c
> index 9413c4abf0b9..c0eb3bb19b23 100644
> --- a/drivers/thermal/int340x_thermal/int3400_thermal.c
> +++ b/drivers/thermal/int340x_thermal/int3400_thermal.c
> @@ -23,7 +23,7 @@ enum int3400_thermal_uuid {
>   INT3400_THERMAL_MAXIMUM_UUID,
>  };
>  
> -static u8 *int3400_thermal_uuids[INT3400_THERMAL_MAXIMUM_UUID] = {
> +static const char
> *int3400_thermal_uuids[INT3400_THERMAL_MAXIMUM_UUID] = {
>   "42A441D6-AE6A-462b-A84B-4A8CE79027D3",
>   "3A95C389-E4B8-4629-A526-C52C88626BAE",
>   "97C68AE7-15FA-499c-B8C9-5DA81D606E0A",
> @@ -141,10 +141,10 @@ static int int3400_thermal_get_uuids(struct
> int3400_thermal_priv *priv)
>   }
>  
>   for (j = 0; j < INT3400_THERMAL_MAXIMUM_UUID; j++) {
> - u8 uuid[16];
> + uuid_le u;
>  
> - acpi_str_to_uuid(int3400_thermal_uuids[j],
> uuid);
> - if (!strncmp(uuid, objb->buffer.pointer,
> 16)) {
> + uuid_le_to_bin(int3400_thermal_uuids[j],
> );
> + if (!uuid_le_cmp(*(uuid_le *)objb-
> >buffer.pointer), u) {
>   priv->uuid_bitmap |= (1 << j);
>   break;
>   }
thanks for the fix.

Acked-by: Zhang Rui <rui.zh...@intel.com>

-rui

Re: [PATCH] ACPI: export acpi events via generic netlink

[Zhang Rui]

On Wed, 2007-07-04 at 14:01 +0200, Johannes Berg wrote:
 On Tue, 2007-07-03 at 15:45 -0400, Len Brown wrote:
  Thanks for including the demo program, Rui, it works for me (tm).
  
  Applied -- with the incremental patch below, which I think
  is correct because the only caller is bus.c, which is part of
  the base kernel, not a module.

 Are you open to reworking this on top of my multicast patches that I
 hope to get in soonish, or should I respin my multicast patches to
 ensure ACPI has a stable family and multicast group number?
 
Hi, Johannes,

I missed the discussion about the multicast issues.
You don't need to reserve a family and group ID for ACPI. I'll rework
this on your patches.:)

But I don't know when these mutlicast patches can be merged while I hope
the function of exporting ACPI event via genetlink can be added ASAP.

I'm okay to hold off on this patch if you think the multicast patches
can be merged soon. Or else I tend to apply it first and send an
additional patch together with your patches later.

Thanks,
Rui
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ACPI: export acpi events via generic netlink

[Zhang Rui]

On Thu, 2007-07-05 at 10:35 +0200, Johannes Berg wrote:
 On Thu, 2007-07-05 at 16:24 +0800, Zhang Rui wrote:
 
  I missed the discussion about the multicast issues.
  You don't need to reserve a family and group ID for ACPI. I'll rework
  this on your patches.:)
 
 I don't want to hold you, don't worry, I can handle it as well.
I got your comments on my original patch and it seems that we don't need
to change a lot with your patches applied. :)

  But I don't know when these mutlicast patches can be merged while I hope
  the function of exporting ACPI event via genetlink can be added ASAP.
  
  I'm okay to hold off on this patch if you think the multicast patches
  can be merged soon. Or else I tend to apply it first and send an
  additional patch together with your patches later.
 
 I personally think it's ready to go and haven't received any further
 comments, but maybe something will come up still. I'll wait a few days
 and then repost as an actual .23 submission.
That would be great. Can we add the ACPI genetlink patch to your patch
set and send them together? I'll refresh it based on your comments.

Thanks,
Rui
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

[Zhang Rui]

On Mon, 2007-06-18 at 11:01 -0400, jamal wrote:
 On Fri, 2007-15-06 at 09:01 +0800, Zhang Rui wrote:
 
   I dont have much time to look at your code given travel, but did you
   try to use your group id instead of the controller's?
   i.e:
   rtnl_open_byproto(rth, nl_mgrp(mydiscoveredacpiid), NETLINK_GENERIC)
   
  Yes. It doesn't work if I use my group id here.
  In fact, I'm using rtnl_open_byproto(rth, 1, NETLINK_GENERIC) now.
  That's why I said that this demo receives all the broadcasted genetlink
  messages.
 
 Ok, by inspection (sorry, still dont have much time) - your kernel code
 is sending to group 1; i.e
 
 genlmsg_multicast(skb, 0, 1, GFP_ATOMIC);
 
 you need to change that to send to your assigned id, i.e:
 genlmsg_multicast(skb, 0, acpi_event_genl_family.id, GFP_ATOMIC);
 
Oh, that's the problem.
Great, now it works happily. :).
Jamal, thanks for your help!

Best regards,
Rui
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ACPI: export acpi events via generic netlink

[Zhang Rui]

From: Zhang Rui [EMAIL PROTECTED]

Export ACPI events via Generic Netlink.
An acpi_event genetlink family message is sent
when an ACPI event is generated.

Note:   The behavior of how ACPI event works nowadays is not changed.
Use genetlink to export ACPI event instead of
/proc/acpi/event someday, but not now.
This patch only adds the function of sending genetlink messages
when an ACPI event is generated.
Attachment is a simple user space utility which can be used to receive
acpi event notifications via netlink.

Thanks to Jamal for his great help.

Signed-off-by: Zhang Rui [EMAIL PROTECTED]
---
 drivers/acpi/bus.c  |4 +
 drivers/acpi/event.c|  166 +---
 include/acpi/acpi_bus.h |3 
 3 files changed, 165 insertions(+), 8 deletions(-)

Index: linux-2.6.22-rc5/drivers/acpi/bus.c
===
--- linux-2.6.22-rc5.orig/drivers/acpi/bus.c2007-06-18 13:44:18.0 
+0800
+++ linux-2.6.22-rc5/drivers/acpi/bus.c 2007-06-19 10:02:33.0 +0800
@@ -292,6 +292,10 @@
if (!device)
return -EINVAL;
 
+   if (acpi_bus_generate_genetlink_event(device, type, data))
+   printk(KERN_WARNING PREFIX
+   Failed to generate an ACPI event via genetlink!\n);
+
/* drop event on the floor if no one's listening */
if (!event_is_open)
return 0;
Index: linux-2.6.22-rc5/drivers/acpi/event.c
===
--- linux-2.6.22-rc5.orig/drivers/acpi/event.c  2007-06-18 13:42:17.0 
+0800
+++ linux-2.6.22-rc5/drivers/acpi/event.c   2007-06-19 11:07:15.0 
+0800
@@ -11,6 +11,8 @@
 #include linux/init.h
 #include linux/poll.h
 #include acpi/acpi_drivers.h
+#include net/netlink.h
+#include net/genetlink.h
 
 #define _COMPONENT ACPI_SYSTEM_COMPONENT
 ACPI_MODULE_NAME(event);
@@ -48,7 +50,6 @@
static int chars_remaining = 0;
static char *ptr;
 
-
if (!chars_remaining) {
memset(event, 0, sizeof(struct acpi_bus_event));
 
@@ -106,23 +107,174 @@
.poll = acpi_system_poll_event,
 };
 
+#ifdef CONFIG_NET
+unsigned int acpi_event_seqnum;
+struct acpi_genl_event {
+   acpi_device_class device_class;
+   char bus_id[15];
+   u32 type;
+   u32 data;
+};
+
+/* attributes of acpi_genl_family */
+enum {
+   ACPI_GENL_ATTR_UNSPEC,
+   ACPI_GENL_ATTR_EVENT,   /* ACPI event info needed by user space */
+   __ACPI_GENL_ATTR_MAX,
+};
+#define ACPI_GENL_ATTR_MAX (__ACPI_GENL_ATTR_MAX - 1)
+
+/* commands supported by the acpi_genl_family */
+enum {
+   ACPI_GENL_CMD_UNSPEC,
+   ACPI_GENL_CMD_EVENT,/* kernel-user notifications for ACPI events */
+   __ACPI_GENL_CMD_MAX,
+};
+#define ACPI_GENL_CMD_MAX (__ACPI_GENL_CMD_MAX - 1)
+
+#define ACPI_GENL_NAME acpi_event
+#define ACPI_GENL_VERSION  0x01
+
+static struct genl_family acpi_event_genl_family = {
+   .id = GENL_ID_GENERATE,
+   .name = ACPI_GENL_NAME,
+   .version = ACPI_GENL_VERSION,
+   .maxattr = ACPI_GENL_ATTR_MAX,
+};
+
+/* .doit: standard command callback */
+static int acpi_genl_cmd_event(struct sk_buff *skb, struct genl_info *info)
+{
+   struct acpi_genl_event *event = info-userhdr;
+
+   if (!event)
+   ACPI_DEBUG_PRINT((ACPI_DB_WARN, ACPI event: NULL\n));
+
+   return 0;
+}
+
+static struct genl_ops acpi_event_genl_ops = {
+   .cmd = ACPI_GENL_CMD_EVENT,
+   .doit = acpi_genl_cmd_event,
+};
+
+int acpi_bus_generate_genetlink_event(struct acpi_device *device,
+ u8 type, int data)
+{
+   struct sk_buff *skb;
+   struct nlattr *attr;
+   struct acpi_genl_event *event;
+   void *msg_header;
+   int size;
+   int result;
+
+   /* allocate memory */
+   size = nla_total_size(sizeof(struct acpi_genl_event)) +
+   nla_total_size(0);
+
+   skb = genlmsg_new(size, GFP_ATOMIC);
+   if (!skb)
+   return -ENOMEM;
+
+   /* add the genetlink message header */
+   msg_header = genlmsg_put(skb, 0, acpi_event_seqnum++,
+acpi_event_genl_family, 0,
+ACPI_GENL_CMD_EVENT);
+   if (!msg_header) {
+   nlmsg_free(skb);
+   return -ENOMEM;
+   }
+
+   /* fill the data */
+   attr =
+   nla_reserve(skb, ACPI_GENL_ATTR_EVENT,
+   sizeof(struct acpi_genl_event));
+   if (!attr) {
+   nlmsg_free(skb);
+   return -EINVAL;
+   }
+
+   event = nla_data(attr);
+   if (!event) {
+   nlmsg_free(skb);
+   return -EINVAL;
+   }
+
+   memset(event, 0, sizeof(struct acpi_genl_event));
+
+   strcpy(event-device_class, device-pnp.device_class);
+   strcpy(event

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

[Zhang Rui]

Hi, Jamal,

Now the genl utility can find the acpi event genetlink family.
And a simple user space demo is finished for handling acpi event.
I really appreciate your help. :)

I think the patch which exposes ACPI events via netlink is ok.
But I still have some problems on
how to listen to specified genetlink family in user space?

I can get the dynamic id for acpi_event genl family.
But I don't know how to use this to receive messages from
specified genl family.
It seems that #genl ctrl monitor has something to do with this,
IMO, rtnl_open_byproto(rth, nl_mgrp(GENL_ID_CTRL), NETLINK_GENERIC) is
used to receive messages from the nlctrl(controller) only, but
unfortunately it never works for me. :(

Any suggestions? What interfaces should I use? Or where can I find some
example code?

Attachment is the simple user space demo I made.
It receives all the broadcasted genetlink messages and only parses the
ones sent by acpi_event genl family.


Thanks,
Rui

On Sun, 2007-05-27 at 09:34 -0400, jamal wrote: 
 On 5/27/07, Zhang Rui [EMAIL PROTECTED] wrote:
 
  I need to write a user application to test my patch.
  Netlink messages can be sent/received using the standard socket API.
 
 sure.
 
  But how to receive Genetlink messages from specified genetlink family?
  There is no socket ACPI with such a parameter, right?
 
 Each module has a unique identifier that it receives dynamically on
  insertion at the kernel.
 
  Do I have to receive all the genetlink messages first?
 
  No, just the ones for your dynamic id. Try what i described first for
  kernel side on the earlier email. I will repeat it here for clarity.
 Then look at genl code and if you have questions i can
  help.
 Note: You need to discover your dynamic id (the iproute2/genl code has a stub
 example code)
  As i told you in the earlier email, in your development:
  - start first by just writting your kernel side.
  - Then use the genl utility - which is part of iproute2 to see if the
  kernel side is discoverable.
 
  E.g if i wanted to discover currently loaded modules on my laptop, i
  would do this:
 
  ---
  [EMAIL PROTECTED]:~$ genl ctrl ls
 
  Name: nlctrl
  ID: 0x10  Version: 0x2  header size: 0  max attribs: 6
  commands supported:
  #1:  ID-0x3  flags-0xe
 
 
  Name: nl80211
  ID: 0x11  Version: 0x1  header size: 0  max attribs: 22
  commands supported:
  #1:  ID-0x1  flags-0xa
  #2:  ID-0x6  flags-0xa
  #3:  ID-0x8  flags-0xa
  #4:  ID-0x3  flags-0xb
  #5:  ID-0x4  flags-0xb
  #6:  ID-0x5  flags-0xb
  #7:  ID-0xa  flags-0xb
  #8:  ID-0xb  flags-0xa
  #9:  ID-0xf  flags-0xb
  #10:  ID-0x10  flags-0xa
  #11:  ID-0x12  flags-0xb
  #12:  ID-0x13  flags-0xa
  #13:  ID-0x15  flags-0xa
  #14:  ID-0x19  flags-0xb
  #15:  ID-0x17  flags-0xb
  #16:  ID-0x18  flags-0xb
  #17:  ID-0x1a  flags-0xb
  #18:  ID-0x1b  flags-0xa
  #19:  ID-0xd  flags-0xb
 
 
  Name: TASKSTATS
  ID: 0x12  Version: 0x1  header size: 0  max attribs: 4
  commands supported:
  #1:  ID-0x1  flags-0xa
  ---
 
  As you can see, i can see from user space the name of the kernel end
  point, its numeric id, what version it is running (so i can make sure
  user space is compatible), what extra header it may have, what the
  maximum number of attributes it can take. The last thing that gets
  listed is the commands, and flags for those commands.
 
  Lets load tipc kernel module and repeat...
 
  ---
 
  [EMAIL PROTECTED]:~$ sudo modprobe tipc
  Name: nlctrl
  ID: 0x10  Version: 0x2  header size: 0  max attribs: 6
  commands supported:
  #1:  ID-0x3  flags-0xe
 
  
  [same as before]
  
 
  Name: TIPC
  ID: 0x13  Version: 0x1  header size: 8  max attribs: 0
  commands supported:
  #1:  ID-0x1  flags-0x2
 
  ===
 
  It would be great if there are any examples on user space communication.
 
 
 
 Bug Thomas - he has written some simple example. I also have some but i
  changed laptops and i have to go and dig it up for you.
  I do have plans for making this easier for people - but havent had time.
  If there is persistence - or someone out there wants to be a hero email
  me privately and i will explain it.
 
  Or should I use libnl library instead?
 
 Why am i answering all these questions if you are fine with using libnl?
 Last time you said you couldnt use a library, no?
 
 cheers,
 jamal
 
 
  Thanks,
  Rui.
 


acpi_genl.tgz
Description: application/compressed-tar

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

[Zhang Rui]

On Thu, 2007-06-14 at 07:28 -0400, jamal wrote:
 On Thu, 2007-14-06 at 16:59 +0800, Zhang Rui wrote:
  Hi, Jamal,
  
  Now the genl utility can find the acpi event genetlink family.
  And a simple user space demo is finished for handling acpi event.
  I really appreciate your help. :)
 
 np.
 
  I think the patch which exposes ACPI events via netlink is ok.
  But I still have some problems on
  how to listen to specified genetlink family in user space?
  
  I can get the dynamic id for acpi_event genl family.
  But I don't know how to use this to receive messages from
  specified genl family.
  It seems that #genl ctrl monitor has something to do with this,
  IMO, rtnl_open_byproto(rth, nl_mgrp(GENL_ID_CTRL), NETLINK_GENERIC) is
  used to receive messages from the nlctrl(controller) only, but
  unfortunately it never works for me. :(
  
 
 I dont have much time to look at your code given travel, but did you
 try to use your group id instead of the controller's?
 i.e:
 rtnl_open_byproto(rth, nl_mgrp(mydiscoveredacpiid), NETLINK_GENERIC)
 
Yes. It doesn't work if I use my group id here.
In fact, I'm using rtnl_open_byproto(rth, 1, NETLINK_GENERIC) now.
That's why I said that this demo receives all the broadcasted genetlink
messages.
 If this doesnt work, ping me and i will take a look  - just expect some
 latency in response.
 
That's great. Thanks.

Best regards,
Rui
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [-mm] ACPI: export ACPI events via netlink

[Zhang Rui]

On Tue, 2007-05-22 at 07:03 -0400, jamal wrote:
 Hi Zhang Rui,
 
 Really cool stuff. Can you instead use genetlink?
 http://linux-net.osdl.org/index.php/Generic_Netlink_HOWTO 
 should help. And if you have more questions post on netdev (not lk).
 
Yes, I have one now. :)
I need to write a user application to test my patch.
Netlink messages can be sent/received using the standard socket API.
But how to receive Genetlink messages from specified genetlink family?
There is no socket ACPI with such a parameter, right?
Do I have to receive all the genetlink messages first?
It would be great if there are any examples on user space communication.

Or should I use libnl library instead?

Thanks,
Rui.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [-mm] ACPI: export ACPI events via netlink

[Zhang Rui]

From: Zhang Rui [EMAIL PROTECTED]

Export ACPI events via netlink.
A netlink message is broadcasted when an ACPI event is generated.

Note: The behaviour of how ACPI event works nowadays is not changed.
Netlink is used to export ACPI event instead of /proc/acpi/event 
someday,
but not now.
This patch only adds the function of sending netlink messages
when an ACPI event is generated.
Following is an example of how to receive ACPI event messages.

#include linux/socket.h
#include linux/netlink.h
#include stdio.h

#define NETLINK_ACPI_EVENT  20
#define SOCK_RAW3

struct acpi_event{
char device_class[20];
char bus_id[15];
unsigned int type;
unsigned int data;
};

struct sockaddr_nl src_addr, dest_addr;
int sock_fd;
struct msghdr msg;
struct iovec iov;


int main (void){
int i = 10;
int result;
struct acpi_event event;

sock_fd = socket(PF_NETLINK, SOCK_RAW, NETLINK_ACPI_EVENT);
if (sock_fd == -1) {
printf(Socket faied!\n);
return 0;
}

src_addr.nl_family = AF_NETLINK;
src_addr.nl_pid = getpid();

src_addr.nl_groups = 1;

result = bind(sock_fd, (struct sockaddr*)src_addr, sizeof(src_addr));
if (result) {
printf(Bind faied! %d.\n, result);
return result;
}

iov.iov_base = (void *)event;
iov.iov_len = sizeof(struct acpi_event);

msg.msg_name = (void *)dest_addr;
msg.msg_namelen = sizeof(dest_addr);
msg.msg_iov = iov;
msg.msg_iovlen = 1;

while(i  0) {
printf(Wait...\n);
result = recvmsg(sock_fd, msg, 0);
if (result == -1) {
printf(Rui: recvmsg failed, error is %d\n, result);
return result;
}
printf(%20s %15s %08x %08x\n,
event.device_class, event.bus_id, event.type, 
event.data);
i--;
}

close(sock_fd);
return 0;
}

Signed-off-by: Zhang Rui [EMAIL PROTECTED]
---
 drivers/acpi/bus.c  |   42 ++
 drivers/acpi/event.c|   25 +
 include/acpi/acpi_bus.h |4 +++-
 include/linux/netlink.h |1 +
 4 files changed, 71 insertions(+), 1 deletion(-)

Index: linux-2.6.22-rc1/drivers/acpi/bus.c
===
--- linux-2.6.22-rc1.orig/drivers/acpi/bus.c2007-05-21 10:18:58.0 
+0800
+++ linux-2.6.22-rc1/drivers/acpi/bus.c 2007-05-21 15:38:06.0 +0800
@@ -37,6 +37,7 @@
 #endif
 #include acpi/acpi_bus.h
 #include acpi/acpi_drivers.h
+#include linux/netlink.h
 
 #define _COMPONENT ACPI_BUS_COMPONENT
 ACPI_MODULE_NAME(bus);
@@ -275,6 +276,43 @@
 /* --
 Event Management
-- 
*/
+#ifdef CONFIG_NET
+struct acpi_bus_netlink_event {
+   acpi_device_class device_class;
+   char bus_id[15];
+   u32 type;
+   u32 data;
+};
+
+static int acpi_bus_generate_netlink_event(struct acpi_device *device,
+   u8 type, int data)
+{
+   struct sk_buff *skb = NULL;
+   struct acpi_bus_netlink_event *event = NULL;
+
+   skb = alloc_skb(sizeof(struct acpi_bus_event), GFP_ATOMIC);
+   if (!skb)
+   return -ENOMEM;
+
+   event = (struct acpi_bus_netlink_event *)
+   skb_put(skb, sizeof(struct acpi_bus_netlink_event));
+   strcpy(event-device_class, device-pnp.device_class);
+   strcpy(event-bus_id, device-dev.bus_id);
+   event-type = type;
+   event-data = data;
+
+   NETLINK_CB(skb).dst_group = 1;
+
+   netlink_broadcast(acpi_event_sock, skb, 0, 1, GFP_ATOMIC);
+   return 0;
+}
+#else
+static int acpi_bus_generate_netlink_event(struct acpi_device *device,
+   u8 type, int data)
+{
+   return 0;
+}
+#endif
 
 static DEFINE_SPINLOCK(acpi_bus_event_lock);
 
@@ -292,6 +330,10 @@
if (!device)
return -EINVAL;
 
+   if (acpi_bus_generate_netlink_event(device, type, data))
+   printk(KERN_WARNING PREFIX
+   Failed to generate a netlink message for ACPI 
event!\n);
+
/* drop event on the floor if no one's listening */
if (!event_is_open)
return 0;
Index: linux-2.6.22-rc1/drivers/acpi/event.c
===
--- linux-2.6.22-rc1.orig/drivers/acpi/event.c  2007-05-16 16:12:46.0 
+0800
+++ linux-2.6.22-rc1/drivers/acpi/event.c   2007-05-21 15:38:32.0 
+0800
@@ -11,6 +11,7 @@
 #include linux/init.h

Re: [PATCH] [-mm] ACPI: export ACPI events via netlink

[Zhang Rui]

On Tue, 2007-05-22 at 07:03 -0400, jamal wrote:
 Hi Zhang Rui,
 
 Really cool stuff. Can you instead use genetlink?
 http://linux-net.osdl.org/index.php/Generic_Netlink_HOWTO 
 should help. And if you have more questions post on netdev (not lk).
 
That's really helpful, thanks.
Will post the second version soon. :)

Thanks,
Rui

 On Tue, 2007-22-05 at 17:47 +0800, Zhang Rui wrote:
  From: Zhang Rui [EMAIL PROTECTED]
  
  Export ACPI events via netlink.
  A netlink message is broadcasted when an ACPI event is generated.
  
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html