All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krishna Kumar <krkumar@us.ibm.com>
Cc: davem@redhat.com, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org,
	netdev@oss.sgi.com, linux-net@vger.kernel.org
Subject: Re: [PATCH] Prefix List patch against 2.5.70
Date: Mon, 02 Jun 2003 10:32:49 -0700	[thread overview]
Message-ID: <3EDB8A41.2080305@us.ibm.com> (raw)
In-Reply-To: <20030531.110249.12960077.yoshfuji@linux-ipv6.org>

Hi Yoshifuji,

Thanks for your comments.

>>+/* prefix list returned to user space in this structure */
>>+struct plist_user_info {
> 
>           ^ip6 or ipv6 or so.
> 
>>+	char name[IFNAMSIZ];		/* interface name */
> 
>         ~~~~~~~~~~~~~~~~~~~duplicate information.
> 

Point noted. That can be removed (prefer to have name instead of ifindex).

>>+	int ifindex;			/* interface index */
>>+	int nprefixes;			/* number of elements in 'prefix' */
>>+	struct var_plist_user_info {	/* multiple elements */
>>+		char flags[3];		/* router advertised flags */
> 
>                      ~~~~~~~~this is not good interface.

This is my mistake. When I added the original interface, it was using the proc
filesystem and it made sense at that time for a user to cat /proc/net/<file> and
actually see the flags. While converting to use netlink, I forgot to change this
to real flags. This was not intended interface :-)


>>+		int plen;		/* prefix length */
>>+		__u32 valid;		/* valid lifetime */
>>+		struct in6_addr ra_addr;/* advertising router */
>>+		struct in6_addr prefix;	/* prefix */
>>+	} plist_vars[0];
>>+};
>>+
>>  extern void			addrconf_init(void);
>>  extern void			addrconf_cleanup(void);
>>
> 
> 
> :
> 
> I think we should use 1 fixed-length message per prefix,
> instead of variable length message.

I had got this idea from "struct fib_info" which also has variable size
structure, but probably it is not worth the extra effort to save a few bytes.

>>+			ipv6_addr_copy(&pinfo->plist_vars[count].ra_addr,
>>+			    &p_el->ra_addr);
>>+			for (i = 0; i < 8; i++)
>>+				pinfo->plist_vars[count].ra_addr.s6_addr16[i] =
>>+				    __constant_ntohs(pinfo->plist_vars[count].ra_addr.s6_addr16[i]);
>>+			ipv6_addr_copy(&pinfo->plist_vars[count].prefix,
>>+			    &p_el->pinfo.prefix);
>>+			for (i = 0; i < p_el->pinfo.prefix_len/16; i++)
>>+				pinfo->plist_vars[count].prefix.s6_addr16[i] =
>>+				    __constant_ntohs(pinfo->plist_vars[count].prefix.s6_addr16[i]);
> 
> 
> Absoletely nasty.
> - don't use charaters to represent flags; use real flags.
> - use network-byte order.

network-byte order ? User will get prefix in network byte order, is that correct  ?

>>+static int prefix_list_proc_dump(char *buffer, char **start, off_t offset,
>>+			   int length)
>>+{
> 
> :
> 
> Please use seq_file.

OK.

> Again, what I proposed was to store prefix information on fib with 
> some flags to represent advertised by routers and give user-space 
> the RA information using new rtattr (RTA_RA6INFO or something like that).
> 
> struct rta_ra6info {
>      u32 rta_ra6flags;
> };
>

In my mail, I had given problems with doing that in the fib. I can look to
convert to fib, but please let me know which kernel routines I should look at.

Thanks,

- KK

  parent reply	other threads:[~2003-06-02 17:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-31  1:15 [PATCH] Prefix List patch against 2.5.70 Krishna Kumar
2003-05-31  2:02 ` YOSHIFUJI Hideaki / 吉藤英明
2003-05-31  6:32   ` David S. Miller
2003-06-17 20:46     ` Krishna Kumar
2003-06-17 20:59       ` YOSHIFUJI Hideaki / 吉藤英明
2003-06-17 21:31         ` Krishna Kumar
2003-06-02 17:32   ` Krishna Kumar [this message]
2003-05-31  6:32 ` David S. Miller
  -- strict thread matches above, loose matches on Subject: below --
2003-06-02 19:46 Krishna Kumar
2003-06-02 21:02 David Stevens
2003-06-03  4:48 ` Pekka Savola
2003-06-03  4:49   ` David S. Miller
2003-06-03  6:42 David Stevens

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=3EDB8A41.2080305@us.ibm.com \
    --to=krkumar@us.ibm.com \
    --cc=davem@redhat.com \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-net@vger.kernel.org \
    --cc=netdev@oss.sgi.com \
    --cc=yoshfuji@linux-ipv6.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.