Question about netlink

Question about netlink

[Krishna Kumar]

Hi,

Some of the netlink routines (eg rtnetlink_dump_ifinfo or inet6_dump_ifaddr) seem to get
user arguments from cb->args['n']. However I was not able to figure out where the
arguments are being set, can anyone help ?

netlink_dump_start() is where the cb gets allocated (initialized to 0), and that calls
netlink_dump(), which calls the assigned routine. I couldn't find where the args gets
initialized to user provided values. Any pointer to what to look for is very much
appreciated.

Thanks,

- KK

Re: Question about netlink

[YOSHIFUJI Hideaki / 吉藤英明]

In article <3F0B10E3.9050700@us.ibm.com> (at Tue, 08 Jul 2003 11:43:47 -0700), Krishna Kumar <krkumar@us.ibm.com> says:

> Some of the netlink routines (eg rtnetlink_dump_ifinfo or inet6_dump_ifaddr) seem to get
> user arguments from cb->args['n']. However I was not able to figure out where the
> arguments are being set, can anyone help ?

Take a look at net/core/rtnelink.c:rtnetlink_dump_ifinfo()
               net/core/neighbour.c:neigh_dump_{info,table}()
and seek the truth. :-)

--yoshfuji

Re: Question about netlink

[Krishna Kumar]

I am still not convinced how it works, though I have been trying to seek the truth for some
time now :-).

These routines 'get' the value of args[0] and then 'set' it to the resultant value. How is
this value set in the first place to the user provided value ? It seems to be initialized
to ZERO in netlink_dump_start(). The only way it seems to use the value is if it gets
called twice from netlink_dump(), the first time cb->args will be set to zero's while the
second time it will have the values set by the first invocation to the same routine. Am I
missing something or is 'args' not intended for user specified arguments ? If so, how
should we access the arguments passed by the user ?

Thanks,

- KK

YOSHIFUJI Hideaki wrote:
> In article <3F0B10E3.9050700@us.ibm.com> (at Tue, 08 Jul 2003 11:43:47 -0700), Krishna Kumar <krkumar@us.ibm.com> says:
> 
> 
>>Some of the netlink routines (eg rtnetlink_dump_ifinfo or inet6_dump_ifaddr) seem to get
>>user arguments from cb->args['n']. However I was not able to figure out where the
>>arguments are being set, can anyone help ?
> 
> 
> Take a look at net/core/rtnelink.c:rtnetlink_dump_ifinfo()
>                net/core/neighbour.c:neigh_dump_{info,table}()
> and seek the truth. :-)
> 
> --yoshfuji
> 

Re: Question about netlink

[kuznet]

Hello!

> These routines 'get' the value of args[0] and then 'set' it to the resultant value. How is
> this value set in the first place to the user provided value ?

It is not. Zero values means that dump starts from the very beginning.
It is supposed to be done at the first entry to the ->dump(),
but selective dumps are not implemented in the most of ->dump() methods.


> missing something or is 'args' not intended for user specified arguments ? If so, how
> should we access the arguments passed by the user ?

The pointer to nlmsg header is kept in cb->nlh. So, you can refer to
it to get user supplied values of selector to rewind the dump to required
point at the first entry or to select some specific entries while scanning
a table.

F.e. look into sch_api.c:tc_dump_tclass(), it scopes dump to a netdevice
(tcp_ifindex), and filters answers to a specific qdisc (tcp_parent).
It is also partial. More finegrain selection is not required, but desired,
feel free to implement. F.e. implementation of "ip route ls root 3ffe::/24",
which translates to selection of a root node for fib6_walk() to a more
specific place and filtering out some nodes while walking, would be cool.

Alexey

[PATCH 6/7] scsi-hw-handler: rm dm-hw-handler code

[michaelc]

From: Mike Christie <michaelc@cs.wisc.edu>

dm-hw-handler is no longer used.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
---
 drivers/md/Makefile        |    2 
 drivers/md/dm-hw-handler.c |  215 --------------------------------------------
 drivers/md/dm-hw-handler.h |   62 -------------
 3 files changed, 1 insertions(+), 278 deletions(-)

diff --git a/drivers/md/Makefile b/drivers/md/Makefile
index 3875408..d2ccc48 100644
--- a/drivers/md/Makefile
+++ b/drivers/md/Makefile
@@ -4,7 +4,7 @@ #
 
 dm-mod-objs	:= dm.o dm-table.o dm-target.o dm-linear.o dm-stripe.o \
 		   dm-ioctl.o dm-io.o kcopyd.o
-dm-multipath-objs := dm-hw-handler.o dm-path-selector.o dm-mpath.o
+dm-multipath-objs := dm-path-selector.o dm-mpath.o
 dm-snapshot-objs := dm-snap.o dm-exception-store.o
 dm-mirror-objs	:= dm-log.o dm-raid1.o
 md-mod-objs     := md.o bitmap.o
diff --git a/drivers/md/dm-hw-handler.c b/drivers/md/dm-hw-handler.c
deleted file mode 100644
index baafaab..0000000
--- a/drivers/md/dm-hw-handler.c
+++ /dev/null
@@ -1,215 +0,0 @@
-/*
- * Copyright (C) 2004 Red Hat, Inc. All rights reserved.
- *
- * This file is released under the GPL.
- *
- * Multipath hardware handler registration.
- */
-
-#include "dm.h"
-#include "dm-hw-handler.h"
-
-#include <linux/slab.h>
-
-struct hwh_internal {
-	struct hw_handler_type hwht;
-
-	struct list_head list;
-	long use;
-};
-
-#define hwht_to_hwhi(__hwht) container_of((__hwht), struct hwh_internal, hwht)
-
-static LIST_HEAD(_hw_handlers);
-static DECLARE_RWSEM(_hwh_lock);
-
-static struct hwh_internal *__find_hw_handler_type(const char *name)
-{
-	struct hwh_internal *hwhi;
-
-	list_for_each_entry(hwhi, &_hw_handlers, list) {
-		if (!strcmp(name, hwhi->hwht.name))
-			return hwhi;
-	}
-
-	return NULL;
-}
-
-static struct hwh_internal *get_hw_handler(const char *name)
-{
-	struct hwh_internal *hwhi;
-
-	down_read(&_hwh_lock);
-	hwhi = __find_hw_handler_type(name);
-	if (hwhi) {
-		if ((hwhi->use == 0) && !try_module_get(hwhi->hwht.module))
-			hwhi = NULL;
-		else
-			hwhi->use++;
-	}
-	up_read(&_hwh_lock);
-
-	return hwhi;
-}
-
-struct hw_handler_type *dm_get_hw_handler(const char *name)
-{
-	struct hwh_internal *hwhi;
-
-	if (!name)
-		return NULL;
-
-	hwhi = get_hw_handler(name);
-	if (!hwhi) {
-		request_module("dm-%s", name);
-		hwhi = get_hw_handler(name);
-	}
-
-	return hwhi ? &hwhi->hwht : NULL;
-}
-
-void dm_put_hw_handler(struct hw_handler_type *hwht)
-{
-	struct hwh_internal *hwhi;
-
-	if (!hwht)
-		return;
-
-	down_read(&_hwh_lock);
-	hwhi = __find_hw_handler_type(hwht->name);
-	if (!hwhi)
-		goto out;
-
-	if (--hwhi->use == 0)
-		module_put(hwhi->hwht.module);
-
-	BUG_ON(hwhi->use < 0);
-
-      out:
-	up_read(&_hwh_lock);
-}
-
-static struct hwh_internal *_alloc_hw_handler(struct hw_handler_type *hwht)
-{
-	struct hwh_internal *hwhi = kmalloc(sizeof(*hwhi), GFP_KERNEL);
-
-	if (hwhi) {
-		memset(hwhi, 0, sizeof(*hwhi));
-		hwhi->hwht = *hwht;
-	}
-
-	return hwhi;
-}
-
-int dm_register_hw_handler(struct hw_handler_type *hwht)
-{
-	int r = 0;
-	struct hwh_internal *hwhi = _alloc_hw_handler(hwht);
-
-	if (!hwhi)
-		return -ENOMEM;
-
-	down_write(&_hwh_lock);
-
-	if (__find_hw_handler_type(hwht->name)) {
-		kfree(hwhi);
-		r = -EEXIST;
-	} else
-		list_add(&hwhi->list, &_hw_handlers);
-
-	up_write(&_hwh_lock);
-
-	return r;
-}
-
-int dm_unregister_hw_handler(struct hw_handler_type *hwht)
-{
-	struct hwh_internal *hwhi;
-
-	down_write(&_hwh_lock);
-
-	hwhi = __find_hw_handler_type(hwht->name);
-	if (!hwhi) {
-		up_write(&_hwh_lock);
-		return -EINVAL;
-	}
-
-	if (hwhi->use) {
-		up_write(&_hwh_lock);
-		return -ETXTBSY;
-	}
-
-	list_del(&hwhi->list);
-
-	up_write(&_hwh_lock);
-
-	kfree(hwhi);
-
-	return 0;
-}
-
-unsigned dm_scsi_err_handler(struct hw_handler *hwh, struct bio *bio)
-{
-#if 0
-	int sense_key, asc, ascq;
-
-	if (bio->bi_error & BIO_SENSE) {
-		/* FIXME: This is just an initial guess. */
-		/* key / asc / ascq */
-		sense_key = (bio->bi_error >> 16) & 0xff;
-		asc = (bio->bi_error >> 8) & 0xff;
-		ascq = bio->bi_error & 0xff;
-
-		switch (sense_key) {
-			/* This block as a whole comes from the device.
-			 * So no point retrying on another path. */
-		case 0x03:	/* Medium error */
-		case 0x05:	/* Illegal request */
-		case 0x07:	/* Data protect */
-		case 0x08:	/* Blank check */
-		case 0x0a:	/* copy aborted */
-		case 0x0c:	/* obsolete - no clue ;-) */
-		case 0x0d:	/* volume overflow */
-		case 0x0e:	/* data miscompare */
-		case 0x0f:	/* reserved - no idea either. */
-			return MP_ERROR_IO;
-
-			/* For these errors it's unclear whether they
-			 * come from the device or the controller.
-			 * So just lets try a different path, and if
-			 * it eventually succeeds, user-space will clear
-			 * the paths again... */
-		case 0x02:	/* Not ready */
-		case 0x04:	/* Hardware error */
-		case 0x09:	/* vendor specific */
-		case 0x0b:	/* Aborted command */
-			return MP_FAIL_PATH;
-
-		case 0x06:	/* Unit attention - might want to decode */
-			if (asc == 0x04 && ascq == 0x01)
-				/* "Unit in the process of
-				 * becoming ready" */
-				return 0;
-			return MP_FAIL_PATH;
-
-			/* FIXME: For Unit Not Ready we may want
-			 * to have a generic pg activation
-			 * feature (START_UNIT). */
-
-			/* Should these two ever end up in the
-			 * error path? I don't think so. */
-		case 0x00:	/* No sense */
-		case 0x01:	/* Recovered error */
-			return 0;
-		}
-	}
-#endif
-
-	/* We got no idea how to decode the other kinds of errors ->
-	 * assume generic error condition. */
-	return MP_FAIL_PATH;
-}
-
-EXPORT_SYMBOL_GPL(dm_register_hw_handler);
-EXPORT_SYMBOL_GPL(dm_unregister_hw_handler);
-EXPORT_SYMBOL_GPL(dm_scsi_err_handler);
diff --git a/drivers/md/dm-hw-handler.h b/drivers/md/dm-hw-handler.h
deleted file mode 100644
index e0832e6..0000000
--- a/drivers/md/dm-hw-handler.h
+++ /dev/null
@@ -1,62 +0,0 @@
-/*
- * Copyright (C) 2004 Red Hat, Inc. All rights reserved.
- *
- * This file is released under the GPL.
- *
- * Multipath hardware handler registration.
- */
-
-#ifndef	DM_HW_HANDLER_H
-#define	DM_HW_HANDLER_H
-
-#include <linux/device-mapper.h>
-
-#include "dm-mpath.h"
-
-struct hw_handler_type;
-struct hw_handler {
-	struct hw_handler_type *type;
-	struct mapped_device *md;
-	void *context;
-};
-
-/*
- * Constructs a hardware handler object, takes custom arguments
- */
-/* Information about a hardware handler type */
-struct hw_handler_type {
-	char *name;
-	struct module *module;
-
-	int (*create) (struct hw_handler *handler, unsigned int argc,
-		       char **argv);
-	void (*destroy) (struct hw_handler *hwh);
-
-	void (*pg_init) (struct hw_handler *hwh, unsigned bypassed,
-			 struct dm_path *path);
-	unsigned (*error) (struct hw_handler *hwh, struct bio *bio);
-	int (*status) (struct hw_handler *hwh, status_type_t type,
-		       char *result, unsigned int maxlen);
-};
-
-/* Register a hardware handler */
-int dm_register_hw_handler(struct hw_handler_type *type);
-
-/* Unregister a hardware handler */
-int dm_unregister_hw_handler(struct hw_handler_type *type);
-
-/* Returns a registered hardware handler type */
-struct hw_handler_type *dm_get_hw_handler(const char *name);
-
-/* Releases a hardware handler  */
-void dm_put_hw_handler(struct hw_handler_type *hwht);
-
-/* Default err function */
-unsigned dm_scsi_err_handler(struct hw_handler *hwh, struct bio *bio);
-
-/* Error flags for err and dm_pg_init_complete */
-#define MP_FAIL_PATH 1
-#define MP_BYPASS_PG 2
-#define MP_ERROR_IO  4	/* Don't retry this I/O */
-
-#endif
-- 
1.4.1.1

Question about NetLink

[Wood, Brian J]

Hello, Alasdair recently said that device-mapper was moving to the a
netlink event reporting model (and I see the patches have been posted).
I found an article (2 years old) describing this at:
http://www.linuxjournal.com/article/7356. I wanted to read up on this
and wondered if this article was a good starting point.

Thank you, 

Brian Wood
Intel Corporation 
Digital Enterprise Group
Manageability & Platform Software Division
brian.j.wood@intel.com

Re: Question about NetLink

[Mike Anderson]

Wood, Brian J <brian.j.wood@intel.com> wrote:
> Hello, Alasdair recently said that device-mapper was moving to the a
> netlink event reporting model (and I see the patches have been posted).
> I found an article (2 years old) describing this at:
> http://www.linuxjournal.com/article/7356. I wanted to read up on this
> and wondered if this article was a good starting point.
> 

I found that it was easier to use the libnl interface.
http://people.suug.ch/~tgr/libnl/

I have previously posted a test program using the libnl interface with the
dm netlink patches. You should be able to find the program in the
archives.

or

I updated the demo program some so ping me if you would like an updated
copy.

-andmike
--
Michael Anderson
andmike@us.ibm.com

RE: Question about NetLink

[Wood, Brian J]

>-----Original Message-----
>From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com]
On
>Behalf Of Mike Anderson
>Sent: Tuesday, June 12, 2007 12:38 PM
>To: device-mapper development
>Subject: Re: [dm-devel] Question about NetLink
>
>Wood, Brian J <brian.j.wood@intel.com> wrote:
>> Hello, Alasdair recently said that device-mapper was moving to the a
>> netlink event reporting model (and I see the patches have been
posted).
>> I found an article (2 years old) describing this at:
>> http://www.linuxjournal.com/article/7356. I wanted to read up on this
>> and wondered if this article was a good starting point.
>>
>
>I found that it was easier to use the libnl interface.
>http://people.suug.ch/~tgr/libnl/
>
>I have previously posted a test program using the libnl interface with
the
>dm netlink patches. You should be able to find the program in the
>archives.
>
>or
>
>I updated the demo program some so ping me if you would like an updated
>copy.

Hello Michael, I just found this email sorted into a folder by mistake.
Could you send me an updated copy of this program (or a link to a site
where it might be posted)? I would like to see netlink in action. 


>
>-andmike
>--
>Michael Anderson
>andmike@us.ibm.com
>
>--
>dm-devel mailing list
>dm-devel@redhat.com
>https://www.redhat.com/mailman/listinfo/dm-devel

RE: Question about NetLink

[Hall, Eric R]

First link on Google when searching for "Mike Anderson libnl":

http://www.redhat.com/archives/dm-devel/2005-November/msg00128.html



>-----Original Message-----
>From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com]
On
>Behalf Of Wood, Brian J
>Sent: Tuesday, September 11, 2007 8:48 AM
>To: device-mapper development
>Subject: RE: [dm-devel] Question about NetLink
>
>>-----Original Message-----
>>From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com]
>On
>>Behalf Of Mike Anderson
>>Sent: Tuesday, June 12, 2007 12:38 PM
>>To: device-mapper development
>>Subject: Re: [dm-devel] Question about NetLink
>>
>>Wood, Brian J <brian.j.wood@intel.com> wrote:
>>> Hello, Alasdair recently said that device-mapper was moving to the a
>>> netlink event reporting model (and I see the patches have been
>posted).
>>> I found an article (2 years old) describing this at:
>>> http://www.linuxjournal.com/article/7356. I wanted to read up on
this
>>> and wondered if this article was a good starting point.
>>>
>>
>>I found that it was easier to use the libnl interface.
>>http://people.suug.ch/~tgr/libnl/
>>
>>I have previously posted a test program using the libnl interface with
>the
>>dm netlink patches. You should be able to find the program in the
>>archives.
>>
>>or
>>
>>I updated the demo program some so ping me if you would like an
updated
>>copy.
>
>Hello Michael, I just found this email sorted into a folder by mistake.
>Could you send me an updated copy of this program (or a link to a site
>where it might be posted)? I would like to see netlink in action.
>
>
>>
>>-andmike
>>--
>>Michael Anderson
>>andmike@us.ibm.com
>>
>>--
>>dm-devel mailing list
>>dm-devel@redhat.com
>>https://www.redhat.com/mailman/listinfo/dm-devel
>
>--
>dm-devel mailing list
>dm-devel@redhat.com
>https://www.redhat.com/mailman/listinfo/dm-devel

Re: Question about NetLink

[Mike Anderson]

Hall, Eric R <eric.r.hall@intel.com> wrote:
> First link on Google when searching for "Mike Anderson libnl":
> 
> http://www.redhat.com/archives/dm-devel/2005-November/msg00128.html
> 


Thanks for providing the link.

Please note that based on discussions held on this list and lkml that I
generated a patch that uses kobject uevents instead of a new netlink
channel. The url to a archive of the article is given below.

http://article.gmane.org/gmane.linux.kernel.device-mapper.devel/3949

The advantage of the kobject uevent interface is that you could trigger
off a udev rule, interface through dbus/hal, or interface directly to the
uevent socket like multipathd does.

I am just finishing up testing on an update to the previous posted patch
that aligns the calls in my patch with the updated kobject uevent
interface in the latest -mm tree. I will post soon.

-andmike
--
Michael Anderson
andmike@us.ibm.com