netlink tester program

netlink tester program

[Randy.Dunlap]

Hi--

I tried to write a simple test program for (rt)netlink, but I didn't
succeed I'm sorry to say.  Does anyone have one or know of one?
[alternative plan is to use kgdb to determine why my test program
is failing...]

I think it should be possible in around 100 lines of code.
I don't want to use iproute2 and libnetlink -- they are much larger
and more complex than a syscall interface test program should be.

I've asked Alexey but I'm getting no replies from him.

Thanks,
--
~Randy

Re: netlink tester program

[David S. Miller]

   From: "Randy.Dunlap" <rddunlap@osdl.org>
   Date: Fri, 30 May 2003 09:00:15 -0700

   I tried to write a simple test program for (rt)netlink, but I didn't
   succeed I'm sorry to say.  Does anyone have one or know of one?
   [alternative plan is to use kgdb to determine why my test program
   is failing...]

I bet if you actually posted your test program, you'll get more
feedback...

Re: netlink tester program

[Randy.Dunlap]

>    From: "Randy.Dunlap" <rddunlap@osdl.org>
>    Date: Fri, 30 May 2003 09:00:15 -0700
>
>    I tried to write a simple test program for (rt)netlink, but I didn't
> succeed I'm sorry to say.  Does anyone have one or know of one?
> [alternative plan is to use kgdb to determine why my test program is
> failing...]
>
> I bet if you actually posted your test program, you'll get more
> feedback...

I did think of that.  Oh well, it's at this URL, bugs and all.

http://www.xenotime.net/linux/ipv6/rtnl_test.c

It's a heavily modified version of a posting like so:
/* original name = testIPv6.c */
/* author:  amit.limaye@patni.com */

And I'll be looking at Herbert's traceroute function also.

Thanks,
~Randy

Re: netlink tester program

[David S. Miller]

   From: "Randy.Dunlap" <rddunlap@osdl.org>
   Date: Fri, 30 May 2003 20:22:12 -0700 (PDT)
   
   Oh well, it's at this URL, bugs and all.
   
   http://www.xenotime.net/linux/ipv6/rtnl_test.c
   
I know you don't want to use libnetlink from iproute2, but I want to
stress that it takes care of all of the minutae of netlink socket
usage that you have to duplicate in your little test program and this
duplication leads to bugs.

Firstly, you needs to be fixed to call recvmsg() multiple times,
you'll get one entry for each recvmsg call in the table you are
querying.

You really need something like rtnl_talk() or rtnl_dump_filter()
from libnetlink to do this properly.

Re: netlink tester program

[Andi Kleen]

> You really need something like rtnl_talk() or rtnl_dump_filter()
> from libnetlink to do this properly.

In case it's helpful I wrote manpages for libnetlink some time ago.

I also have some simple example programs using it. Other examples
can be found in the zebra or bird source code.

-Andi

-Andi

libnetlink(3)                                       libnetlink(3)



NAME
       libnetlink - A library for accessing the netlink service

SYNOPSIS
       #include <asm/types.h>
       #include <libnetlink.h>
       #include <linux/netlink.h>
       #include <linux/rtnetlink.h>

       int rtnl_open(struct rtnl_handle *rth, unsigned subscriptions)

       int rtnl_wilddump_request(struct rtnl_handle *rth, int family, int type)

       int rtnl_send(struct rtnl_handle *rth, char *buf, int len)

       int rtnl_dump_request(struct rtnl_handle *rth, int type, void *req, int len)

       int rtnl_dump_filter(struct rtnl_handle *rth,
                      int (*filter)(struct sockaddr_nl *, struct nlmsghdr *n, void *),
                      void *arg1,
                      int (*junk)(struct sockaddr_nl *,struct nlmsghdr *n, void *),
                      void *arg2)

       int rtnl_talk(struct rtnl_handle *rtnl, struct nlmsghdr *n, pid_t peer,
                  unsigned groups, struct nlmsghdr *answer,
                  int (*junk)(struct sockaddr_nl *,struct nlmsghdr *n, void *),
                  void *jarg)

       int rtnl_listen(struct rtnl_handle *rtnl,
                  int (*handler)(struct sockaddr_nl *,struct nlmsghdr *n, void *),
                  void *jarg)

       int rtnl_from_file(FILE *rtnl,
                  int (*handler)(struct sockaddr_nl *,struct nlmsghdr *n, void *),
                  void *jarg)

       int addattr32(struct nlmsghdr *n, int maxlen, int type, __u32 data)

       int addattr_l(struct nlmsghdr *n, int maxlen, int type, void *data, int alen)

       int rta_addattr32(struct rtattr *rta, int maxlen, int type, __u32 data)

       int rta_addattr_l(struct rtattr *rta, int maxlen, int type, void *data, int alen)

DESCRIPTION
       libnetlink   provides   a   higher   level   interface  to
       rtnetlink(7).  The read functions return 0 on success  and
       a  negative  errno  on failure.  The send functions return
       the amount of data sent, or -1 on error.

       rtnl_open
              Open a rtnetlink socket and save the state into the
              rth handle. This handle is passed to all subsequent
              calls.  subscriptions is a bitmap of the  rtnetlink
              multicast groups the socket will be a member of.


       rtnl_wilddump_request
              Request a full dump of the type database for family
              addresses.  type is a rtnetlink message type.


       rtnl_dump_request
              Request a full dump of the type  data  buffer  into
              buf   with  maximum  length  of  len.   type  is  a
              rtnetlink message type.


       rtnl_dump_filter
              Receive netlink data after a request and filter it.
              The  filter callback checks if the received message
              is wanted. It gets the source address of  the  mes-
              sage,  the  message itself and arg1 as arguments. 0
              as return means that the filter passed, a  negative
              value  is  returned  by rtnl_dump_filter in case of
              error. NULL for filter means to not use  a  filter.
              junk is used to filter messages not destined to the
              local socket.  Only one message bundle is received.
              Unless  there  is no message pending, this function
              does not block.


       rtnl_listen
              Receive netlink data after a request and pass it to
              handler.   handler is a callback that gets the mes-
              sage source address, the message  itself,  and  the
              jarg  cookie  as  arguments. It will get called for
              all received messages.  Only one message bundle  is
              received.  Unless  there is no message pending this
              function does not block.


       rtnl_from_file
              Works like rtnl_listen, but reads a netlink message
              bundle  from  the file file and passes the messages
              to handler for parsing. The file contains raw  data
              as received from a rtnetlink socket.

       The  following  functions  are  useful to construct custom
       rtnetlink messages. For simple database dumping with  fil-
       tering  it  is  better  to  use the higher level functions
       above. See rtnetlink(3) and netlink(3) on how to  generate
       a  rtnetlink  message.  The  following  utility  functions
       require  a  continuous  buffer  that  already  contains  a
       netlink message header and a rtnetlink request.


       rtnl_send
              Send  the rtnetlink message in buf of length len to
              handle rth.


       addattr32
              Add a __u32 attribute of type type and  with  value
              data  to  netlink  message  n,  which  is part of a
              buffer of length maxlen.


       addattr_l
              Add a variable length attribute of  type  type  and
              with  value data and alen length to netlink message
              n, which is part of  a  buffer  of  length  maxlen.
              data is copied.


       rta_addattr32
              Initialize the rtnetlink attribute rta with a __u32
              data value.


       rta_addattr32
              Initialize the rtnetlink attribute rta with a vari-
              able length data value.


BUGS
       The  functions sometimes use fprintf and exit when a fatal
       error occurs.  This library should be named  librtnetlink.


AUTHORS
       netlink/rtnetlink   was  designed  and  written  by  Alexey
       Kuznetsov.  Andi Kleen wrote the man page.


SEE ALSO
       netlink(7), rtnetlink(7)
       /usr/include/linux/rtnetlink.h



                                                    libnetlink(3)


> 

Re: netlink tester program

[Randy.Dunlap]

On Sat, 31 May 2003 14:09:40 +0200 Andi Kleen <ak@suse.de> wrote:

| > You really need something like rtnl_talk() or rtnl_dump_filter()
| > from libnetlink to do this properly.
| 
| In case it's helpful I wrote manpages for libnetlink some time ago.
| 
| I also have some simple example programs using it. Other examples
| can be found in the zebra or bird source code.

Does this man page live somewhere?  Do some distros ship it?

Where can I find your example programs that use it?

Couple of corrections below....


|        rtnl_listen
|               Receive netlink data after a request and pass it to
|               handler.   handler is a callback that gets the mes-
|               sage source address, the message  itself,  and  the
|               jarg  cookie  as  arguments. It will get called for
+                                            It will be called for
{'get' should usually be avoided when easily done}
|               all received messages.  Only one message bundle  is
|               received.  Unless  there is no message pending this
|               function does not block.
| 
| 
|        rta_addattr32
|               Initialize the rtnetlink attribute rta with a __u32
|               data value.
| 
| 
|        rta_addattr32
+        rta_addattr_l
|               Initialize the rtnetlink attribute rta with a vari-
|               able length data value.


--
~Randy

Re: netlink tester program

[Randy.Dunlap]

On Fri, 30 May 2003 23:42:11 -0700 (PDT) "David S. Miller" <davem@redhat.com> wrote:

|    From: "Randy.Dunlap" <rddunlap@osdl.org>
|    Date: Fri, 30 May 2003 20:22:12 -0700 (PDT)
|    
|    Oh well, it's at this URL, bugs and all.
|    
|    http://www.xenotime.net/linux/ipv6/rtnl_test.c
|    
| I know you don't want to use libnetlink from iproute2, but I want to
| stress that it takes care of all of the minutae of netlink socket
| usage that you have to duplicate in your little test program and this
| duplication leads to bugs.
| 
| Firstly, you needs to be fixed to call recvmsg() multiple times,
| you'll get one entry for each recvmsg call in the table you are
| querying.

Yes, I noticed that I was getting only 1 msg there.

| You really need something like rtnl_talk() or rtnl_dump_filter()
| from libnetlink to do this properly.

Does anyone have documentation (or semantics) for rtnl_talk()?
or just some blurb about it?
Andi's libnetlink man page missed it somehow.

Thanks,
--
~Randy

Re: netlink tester program

[David S. Miller]

   From: "Randy.Dunlap" <rddunlap@osdl.org>
   Date: Mon, 2 Jun 2003 14:04:52 -0700

   Does anyone have documentation (or semantics) for rtnl_talk()?
   or just some blurb about it?

I always have to wonder about someone who can't live with just
working code to study, and absolutely requires some document
describing it.

What is better or more accurate description than code itself!?!?!

Re: netlink tester program

[David Brownell]

David S. Miller wrote:
>    From: "Randy.Dunlap" <rddunlap@osdl.org>
>    Date: Mon, 2 Jun 2003 14:04:52 -0700
> 
>    Does anyone have documentation (or semantics) for rtnl_talk()?
>    or just some blurb about it?
> 
> I always have to wonder about someone who can't live with just
> working code to study, and absolutely requires some document
> describing it.
> 
> What is better or more accurate description than code itself!?!?!

Well, the difference between code and its spec is
generally a bug that needs to be fixed ... which
can be in the code as well as in the spec.  And for
reasonable design specs, it's more likely in the code.

But if there's only the code, it gets a lot more
troublesome when things don't behave "as expected".

People who are in a position to change the code
to meet their expectations may not care, but that's
rarely a significant chunk of the user community.

And in particular, writing tests against the code
is generally the wrong way to go.  They need to be
written against some kind of spec.

- Dave

Re: netlink tester program

[David S. Miller]

   From: David Brownell <david-b@pacbell.net>
   Date: Mon, 02 Jun 2003 18:56:23 -0700
   
   Well, the difference between code and its spec is
   generally a bug that needs to be fixed ...

See, a document is NOT the spec, the code is the spec.

Because where the document is wrong, the code determines
the final answer.  This is true in all cases.

I cannot tell you how much time I've seen people waste because they
went for documents first, only to find them to be inaccurate for some
corner case whilst the code has all of the accurate answers.

When I see someone want docs, I interpret this as "I don't want to
have to think or have to comprehend something, I'm too lazy to read
the code."  Well, such laziness leads the person in question only
to be suscpetible to all of the inaccuracies and disconnect that
always will exist between said docs (if they even exist) and the
code.

It is also the mechanism that leads people to send patches that add
arbitrary crap all over the ipv4/ipv6 code, totally missing the point
that the routing and/or netlink layer did %99 of what they wanted
already.

For example, I added a hoplimit route attribute to RTNETLINK.  Who
documented this?  What document can you read that would teach you
about this feature?  None.

And don't tell me this is a doc bug, every time I make a change the
documentation will be instantly buggy and I'm not going to be required
to document every diff I make to the tree.

Re: netlink tester program

[John S. Denker]

On 06/02/2003 05:56 PM, David S. Miller wrote:
 >>
 >> I always have to wonder about someone who can't live with just
 >> working code to study, and absolutely requires some document
 >> describing it.
 >>
 >> What is better or more accurate description than code itself!?!?!

I am very grateful for the kindness of those who
have written the code in question and made it
available to help others.  I wish to repay that
with help and kindness, not the opposite.  Today
I can help by speaking the truth, and the truth
is that documentation is sorely needed.

There's no point in writing code if few people
use it.  Linux is hanging in there at a few
percent market share.  That's not going to grow
unless there is better documentation.


On 06/02/2003 09:56 PM, David Brownell replied:
 >
 > Well, the difference between code and its spec is
 > generally a bug that needs to be fixed ... which
 > can be in the code as well as in the spec.  And for
 > reasonable design specs, it's more likely in the code.
 >
 > But if there's only the code, it gets a lot more
 > troublesome when things don't behave "as expected".
 >
 > People who are in a position to change the code
 > to meet their expectations may not care, but that's
 > rarely a significant chunk of the user community.
 >
 > And in particular, writing tests against the code
 > is generally the wrong way to go.  They need to be
 > written against some kind of spec.

I have to agree with Mr. Brownell on this one.


 >> What is better or more accurate description than code itself!?!?!

There are two ideas mixed up there.
  -- Better documentation.
  -- Accurate description.

1) Yes, code is the most accurate description of the code.
But it is not to be confused with good documentation.

2) Documentation should be clear and concise.
Code must attend to all the details.

3) Sometimes efficiency requires that the code be
tricky.  Documentation must not be tricky.

4) In theory, very well-commented code might
approximate its own documentation.  But I haven't
seen any such code lately.  Here are _all_ the
comments from xfrm_input.c, a 454-line file:

/* Fetch spi and seq frpm ipsec header */
         /* Allocate new secpath or COW existing one. */
/* Fetch spi and seq frpm ipsec header */
                 iph = skb->nh.ipv6h; /* ??? */
                 if (x->props.mode) { /* XXX */
         /* Allocate new secpath or COW existing one. */
#endif /* CONFIG_IPV6 || CONFIG_IPV6_MODULE */


If you were teaching a programming course, how would
you grade an assignment turned in with that level of
commenting?

5) In the engine of a piston-driven airplane, there
are two spark plugs in every cylinder.  Obviously
that costs twice as much and weighs twice as much
as having only one.  But the redundancy makes the
system thousands of times more reliable.

Similarly, writing code _and_ documetation is about
twice as expensive as writing the code alone.  But
the redundancy makes it possible to achieve much
greater reliability.  Also maintainability and
extensibility.

6) Adding extra vehemence '!?!?!' does not add
clarity to the discussion.

*) et cetera.

Re: netlink tester program

[David S. Miller]

   From: "John S. Denker" <jsd@monmouth.com>
   Date: Mon, 02 Jun 2003 22:33:57 -0400
   
   There's no point in writing code if few people
   use it.

People use this "undocumented" area of the kernel every
time their machine boots up.

Re: netlink tester program

[John S. Denker]

I wrote in part:
 >
 >    There's no point in writing code if few people
 >    use it.


On 06/02/2003 10:38 PM, David S. Miller wrote:
> 
> People use this "undocumented" area of the kernel every
> time their machine boots up.

That's not inconsistent with what I was saying.

Mr. Miller said people use it.  That's true.  Some
people use it.

I said few people use it.  That's true.  The context
of my original statement was:

> Linux is hanging in there at a few
> percent market share.  That's not going to grow
> unless there is better documentation.

This is supposed to be open-source software,
n'est-ce pas?

Software that is copylefted but not documented
is open according to the letter of the law, but
lacks the spirit of openness.

Mr. Miller is very smart and has spent years
getting up to speed in this area.  Is the code
to be open only to those who are equally smart
and willing to invest equally huge amounts of
time?

When people ask for help in understanding the
code, it might mean they need help in understanding
the code.

Re: netlink tester program

[David S. Miller]

   From: "John S. Denker" <jsd@monmouth.com>
   Date: Mon, 02 Jun 2003 23:20:56 -0400
   
   Mr. Miller is very smart and has spent years
   getting up to speed in this area.  Is the code
   to be open only to those who are equally smart
   and willing to invest equally huge amounts of
   time?

Are legal rights only available to people who understand
the law and have a legal degree?

No, this is why we hire lawyers if we choose not to study
law ourselves.

Your logic is heavily flawed.

Re: netlink tester program

[Randy.Dunlap]

>    From: "Randy.Dunlap" <rddunlap@osdl.org>
>    Date: Mon, 2 Jun 2003 14:04:52 -0700
>
>    Does anyone have documentation (or semantics) for rtnl_talk()?
>    or just some blurb about it?
>
> I always have to wonder about someone who can't live with just
> working code to study, and absolutely requires some document
> describing it.
>
> What is better or more accurate description than code itself!?!?!

The code is absolute, no doubt about it.  It is the authority.
That doesn't make it right in all cases AFAIK.

And it lacks documentation, even in the source files.
There are no semantics or meaning associated with that code
except by the people who developed it.  I'm not one of them,
so I'm trying to ask them or others who know.

And yes, I'm looking for the way that it should be done (IMHO)
instead of the way it is done.

Now, given that I think that the netlink interface is poorly
documented, and that I'm trying to add some kernel code that
uses it, and that I'm trying to test said kernel code with a
userspace test program, I also plan to add such documentation
that I think is warranted to make it easy to use, even by
non-kernel devevlopers.  This documentation might end up
living outside of the kernel tree -- that's OK.  But in any
case, from both private and mailing list emails, I'm not alone
in thinking that it's needed.

~Randy

Re: netlink tester program

[David Brownell]

>    Well, the difference between code and its spec is
>    generally a bug that needs to be fixed ...
> 
> See, a document is NOT the spec, the code is the spec.

That's hardly the only development model.


> Because where the document is wrong, the code determines
> the final answer.  This is true in all cases.

Not "all".  "Code-as-spec" works well when there's only
one code base, but otherwise it's flawed.  Even the model
of a "reference implementation" is trouble ... since it
invariably evolves into "everyone should use this code".

Of course, bugs that stay unfixed for a long time can
force the "spec" to change.  It's a great vendor lock-in
tool, and it can happen accidentally too.  But most folk
view such interop problems as bugs, not features.


> I cannot tell you how much time I've seen people waste because they
> went for documents first, only to find them to be inaccurate for some
> corner case whilst the code has all of the accurate answers.

Or where they notice the code is wrong in that corner case,
and they can prove that easily since the spec (implemented
correctly in several other places) and the code disagree.

Or where this implementation uses this answer, and that one
uses that answer ... and the poor user gets caught in the
middle of a finger pointing war, which can't be resolved
since each implementation's developers claim to be "the spec",
and the user eventually gives up saying "a pox on you all!"

You clipped out the text where I pointed out that bugs can
be in specs as well as code.  They can be fixed there, too.


> When I see someone want docs, I interpret this as "I don't want to
> have to think or have to comprehend something, I'm too lazy to read
> the code."  Well, such laziness leads the person in question only
> to be suscpetible to all of the inaccuracies and disconnect that
> always will exist between said docs (if they even exist) and the
> code.

That's an *extremely negative interpretation*, and while I've seen
people that are that lazy, they happen to be in the minority
of people I've known to ask for docs/specs.  (Thank the Gods!)

Consider one thing that docs/specs do that code can't:  give
the "30,000 foot view" rather than the "tree level view".  It's
not "lazy" to avoid using the tree-level view; sometimes such
low-level perspectives can be counterproductive.

People ask for docs for lots of reasons, and most of them have
nothing at all to do with laziness.

- Dave

Re: netlink tester program

[David S. Miller]

   From: "Randy.Dunlap" <rddunlap@osdl.org>
   Date: Mon, 2 Jun 2003 20:32:22 -0700 (PDT)

   The code is absolute, no doubt about it.  It is the authority.
   That doesn't make it right in all cases AFAIK.
   
I totally agree.

   Now, given that I think that the netlink interface is poorly
   documented, and that I'm trying to add some kernel code that
   uses it, and that I'm trying to test said kernel code with a
   userspace test program, I also plan to add such documentation
   that I think is warranted to make it easy to use, even by
   non-kernel devevlopers.

This is exactly how things should work.  Where there is a need
for X _AND_ someone willing to create X, it will be created.

No arguments from me on this :-)

Re: netlink tester program

[David Brownell]

John S. Denker wrote:

> Similarly, writing code _and_ documetation is about
> twice as expensive as writing the code alone.  But
> the redundancy makes it possible to achieve much
> greater reliability.  Also maintainability and
> extensibility.

Excellent points.  The developement process needs
to address communities other than the folk writing
the code ... like the people who inherit that code,
and the ones trying to use it.  (Testing being a
rather specialize type of "use".)

- Dave

Re: netlink tester program

[David S. Miller]

   From: David Brownell <david-b@pacbell.net>
   Date: Mon, 02 Jun 2003 20:34:19 -0700

   > See, a document is NOT the spec, the code is the spec.
   
   That's hardly the only development model.
   
It's the one that works for _me_ and Alexey and myself, and we're the
ones doing all the work.

When someone doing the work desires the docs and desires to
WRITE it, it will appear.
   
You can expect exactly nothing more in our development model.
If you require me to write the docs, you misunderstand how the
system works :)

   You clipped out the text where I pointed out that bugs can
   be in specs as well as code.  They can be fixed there, too.
   
Very true.  So when Randy writes the more detailed netlink/rtnetlink
docs, we'll be happy :-)
   
There is even an official IETF RFC written by Jamal, Alexey, and
others documenting netlink btw :-))))))))))))

Did anybody notice this?

Re: netlink tester program

[John S. Denker]

On 06/02/2003 11:22 PM, David S. Miller wrote:
> 
> Are legal rights only available to people who understand
> the law and have a legal degree?
> 
> No, this is why we hire lawyers if we choose not to study
> law ourselves.

If we are taking the legal system as our
model of openness, then open-source software
has come to a sorry pass indeed.

=========

It is also important to distinguish what's best
for *you* and what's best for the project.
Maybe *you* don't want to be responsible for
doing all the documentation.  I can understand
that.  But the project as a whole would be better
off it it had better documentation.  Perhaps
you could recruit other folks to help with this.
But disdaining the whole concept isn't a good
way to start the recruiting.

Re: netlink tester program

[David S. Miller]

   From: "John S. Denker" <jsd@monmouth.com>
   Date: Mon, 02 Jun 2003 23:41:38 -0400
   
   If we are taking the legal system as our
   model of openness, then open-source software
   has come to a sorry pass indeed.
   
It does have connections where a "user" wants to
do something with FOO but does not wish to do the
legwork necessary to be an expert in FOO.  They hire
an expert.

Or, in our case, they make an expert interested in the
thing they want to do :-)))
   
   It is also important to distinguish what's best
   for *you* and what's best for the project.
   Maybe *you* don't want to be responsible for
   doing all the documentation.

I'm not even going to attempt to document something that
moves as fast as the kernel.

I go to bookstores and I see many excellent attempts to document
kernel internals, but these books are frozen in time.  Specifically
they are frozen in the time of the moment the kernel they write for is
published.  As a consequence they are all obsolete the moment they are
published.

Some poor student reads these books, written against 2.4.8 or
whatever, then they go and try to contribute to 2.5.x and it
doesn't work except for certain kinds of drivers where we've
kept the APIs more or less the same.

But I don't care that people do this, just don't require that I do
it.

I think this extra fluidity we get from being able to change so fast
is a strength not a weakness.

Re: netlink tester program

[Randy.Dunlap]

>    From: David Brownell <david-b@pacbell.net>
>    Date: Mon, 02 Jun 2003 20:34:19 -0700
>
>    > See, a document is NOT the spec, the code is the spec.
>
>    That's hardly the only development model.
>
> It's the one that works for _me_ and Alexey and myself, and we're the ones
> doing all the work.

Do you want it to remain that way?

> When someone doing the work desires the docs and desires to
> WRITE it, it will appear.
>
> You can expect exactly nothing more in our development model.
> If you require me to write the docs, you misunderstand how the
> system works :)
>
>    You clipped out the text where I pointed out that bugs can
>    be in specs as well as code.  They can be fixed there, too.
>
> Very true.  So when Randy writes the more detailed netlink/rtnetlink docs,
> we'll be happy :-)
>
> There is even an official IETF RFC written by Jamal, Alexey, and
> others documenting netlink btw :-))))))))))))
>
> Did anybody notice this?

Yes.

~Randy

Re: netlink tester program

[David S. Miller]

   From: "Randy.Dunlap" <rddunlap@osdl.org>
   Date: Mon, 2 Jun 2003 20:49:32 -0700 (PDT)

   > It's the one that works for _me_ and Alexey and myself, and we're
   > the ones doing all the work.
   
   Do you want it to remain that way?
   
Doesn't matter to _us_, _we_ know how these things work
and how to use them.  If we don't, we'll read the code to
learn this.

Other's care, and if someone writes the docs for _them_,
that is _fine_.

What I object to is "hey we have to have docs, why didn't
dave and alexey write them". :)

Franks a lot,
David S. Miller
davem@redhat.com

Re: netlink tester program

[Randy.Dunlap]

>    It is also important to distinguish what's best
>    for *you* and what's best for the project.
>    Maybe *you* don't want to be responsible for
>    doing all the documentation.
>
> I'm not even going to attempt to document something that
> moves as fast as the kernel.

That point is a real problem...

> I go to bookstores and I see many excellent attempts to document
> kernel internals, but these books are frozen in time.  Specifically they are
> frozen in the time of the moment the kernel they write for is published.  As
> a consequence they are all obsolete the moment they are published.

No doubt.

> Some poor student reads these books, written against 2.4.8 or
> whatever, then they go and try to contribute to 2.5.x and it
> doesn't work except for certain kinds of drivers where we've
> kept the APIs more or less the same.
>
> But I don't care that people do this, just don't require that I do it.

Sure.  Are you willing to answer questions about it at least?

> I think this extra fluidity we get from being able to change so fast is a
> strength not a weakness.

If it were only a strength, that would be great.
I believe that it's both, however.

~Randy

Re: netlink tester program

[David S. Miller]

   From: "Randy.Dunlap" <rddunlap@osdl.org>
   Date: Mon, 2 Jun 2003 20:54:01 -0700 (PDT)

   > But I don't care that people do this, just don't require that I do it.
   
   Sure.  Are you willing to answer questions about it at least?

As long as others like Alexey and Jamal help field these questions and
it's not just me sitting here becoming a Linux development support
service :-)

Re: netlink tester program

[Hisham Kotry]

--- "David S. Miller" <davem@redhat.com> wrote:
> There is even an official IETF RFC written by Jamal,
> Alexey, and
> others documenting netlink btw :-))))))))))))
> 
> Did anybody notice this?

It was defenitly a nice read, but the netlink2 draft
is somewhat inconsistent, it mentions reducing the
32-bit length field to 16-bits and equally
distributing the remaining 16-bits between the new
version and extended flags fields, but the draft makes
no further refrence to the version field. Infact the
netlink2 message header diagram on page 16, as well as
the pseudo message on page 28, show a 16-bits extended
flags field with no version field in the header. So
this is probably one of those cases in wich specs
aren't clear enough and code usually has the final
word in such situations.

I mailed Jamal about this a while ago but never got a
reply back.

BTW, is netlink2 support planned for linux in the near
future?

David, sorry for the private mail, but it was
unintentional as I (by mistake) pressed reply instead
of reply all.

Chaow,
kotry


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

Re: netlink tester program

[Jamal Hadi]

On Tue, 3 Jun 2003, Hisham Kotry wrote:

> It was defenitly a nice read, but the netlink2 draft
> is somewhat inconsistent, it mentions reducing the
> 32-bit length field to 16-bits and equally
> distributing the remaining 16-bits between the new
> version and extended flags fields, but the draft makes
> no further refrence to the version field. Infact the
> netlink2 message header diagram on page 16, as well as
> the pseudo message on page 28, show a 16-bits extended
> flags field with no version field in the header. So
> this is probably one of those cases in wich specs
> aren't clear enough and code usually has the final
> word in such situations.
>
> I mailed Jamal about this a while ago but never got a
> reply back.
>

apologies, I actually have a unrelated daytime job that tends to keep me
too occupied at times ;->

Netlink2 draft is work in progress. The draft tends to lag reality.
I believe what you refer to has been fixed. Refer to the slides at:
http://www.zurich.ibm.com/~rha/netlink2.pdf

> BTW, is netlink2 support planned for linux in the near
> future?
>

You will see code from us that is GPL. Consider netlink2 as a distributed
netlink. netlink is already proven so why reinvent the wheel?
Essentially you should be able to manager clusters of linux network
devices (think firewalls, routers etc) with netlink/netlink2.
There are some mechanisms for distributdness that are missing. These are
the holes we are going to fill.

Note some of the stuff i am working on at:
www.cyberus.ca/~hadi/patches/action which fits the whole forces paradigm
and works quiet well with netlink today and netlink2 next.
(I stopped updating that web page for sometime now, talk to me if
interested in the patches and if you would like to help in testing,
coding, etc)

cheers,
jamal

Re: netlink tester program

[Mr. James W. Laferriere]

	Hello Jamal ,  Is there a time frame to update the draft ?
	Many people do not see these lists .  Yours & Mr. Haas's work is
	only viewable to these thru the ietf draft/rfc/... process .
	Rather narrow veiw but necessary at times .  Tia ,  JimL

On Sun, 8 Jun 2003, Jamal Hadi wrote:
...snip...
> apologies, I actually have a unrelated daytime job that tends to keep me
> too occupied at times ;->
>
> Netlink2 draft is work in progress. The draft tends to lag reality.
> I believe what you refer to has been fixed. Refer to the slides at:
> http://www.zurich.ibm.com/~rha/netlink2.pdf
>
> > BTW, is netlink2 support planned for linux in the near
> > future?
>
> You will see code from us that is GPL. Consider netlink2 as a distributed
> netlink. netlink is already proven so why reinvent the wheel?
> Essentially you should be able to manager clusters of linux network
> devices (think firewalls, routers etc) with netlink/netlink2.
> There are some mechanisms for distributdness that are missing. These are
> the holes we are going to fill.
>
> Note some of the stuff i am working on at:
> www.cyberus.ca/~hadi/patches/action which fits the whole forces paradigm
> and works quiet well with netlink today and netlink2 next.
> (I stopped updating that web page for sometime now, talk to me if
> interested in the patches and if you would like to help in testing,
> coding, etc)

-- 
       +------------------------------------------------------------------+
       | James   W.   Laferriere | System    Techniques | Give me VMS     |
       | Network        Engineer |     P.O. Box 854     |  Give me Linux  |
       | babydr@baby-dragons.com | Coudersport PA 16915 |   only  on  AXP |
       +------------------------------------------------------------------+

Re: netlink tester program

[David S. Miller]

   From: Jamal Hadi <hadi@shell.cyberus.ca>
   Date: Sun, 8 Jun 2003 21:35:09 -0400 (EDT)

   Netlink2 draft is work in progress. The draft tends to lag reality.
   I believe what you refer to has been fixed. Refer to the slides at:
   http://www.zurich.ibm.com/~rha/netlink2.pdf
 ...   
   Consider netlink2 as a distributed netlink.

Beautiful, if you're going to allow this protocol to go over the wire,
you have to choose a network byte order and swap in/out of it.

Should be fun :)

Unfortunately I see no mention of this issue in the slides, should I
be scared?