DECnet routing rule resolution

2007-03-29 Thread Steven Whitehouse
Hi,

One of the effects of the recent tidy up of the DECnet routing rules
code is that we are no longer able to see the difference between reading
a rule of type FR_ACT_UNREACHABLE returning -ENETUNREACH and simply
running out of rules to look at, which also returns the same thing.

The DECnet code used to return -ESRCH if it ran out of rules in which
case the test in dn_route.c (which resulted in DECnet falling back to
endnode routing in the -ESRCH case) no longer works.

So there seems to be several options to try and solve this: one is to
change the error return for running out of rules in
fib_rules.c:fib_rules_lookup() to something else (but then that has a
knock on effect in the ipv4 code). Another is to add the not found
error return as a parameter in the struct fib_rules_ops so that both
protocols can have their preferred error return. Both solutions seem a
bit messy, so I thought I'd ask for some guidance on this before writing
a patch,


Steve.


-
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: DECnet routing rule resolution

2007-03-29 Thread David Miller
From: Steven Whitehouse [EMAIL PROTECTED]
Date: Thu, 29 Mar 2007 17:24:10 +0100

 One of the effects of the recent tidy up of the DECnet routing rules
 code is that we are no longer able to see the difference between reading
 a rule of type FR_ACT_UNREACHABLE returning -ENETUNREACH and simply
 running out of rules to look at, which also returns the same thing.
 
 The DECnet code used to return -ESRCH if it ran out of rules in which
 case the test in dn_route.c (which resulted in DECnet falling back to
 endnode routing in the -ESRCH case) no longer works.
 
 So there seems to be several options to try and solve this: one is to
 change the error return for running out of rules in
 fib_rules.c:fib_rules_lookup() to something else (but then that has a
 knock on effect in the ipv4 code). Another is to add the not found
 error return as a parameter in the struct fib_rules_ops so that both
 protocols can have their preferred error return. Both solutions seem a
 bit messy, so I thought I'd ask for some guidance on this before writing
 a patch,

I think we should be able to return -ESRCH (a more sensible error
value if you ask me) across the board.

Thomas what do you think?
-
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: DECnet routing rule resolution

2007-03-29 Thread Thomas Graf
* David Miller [EMAIL PROTECTED] 2007-03-29 11:43
 From: Steven Whitehouse [EMAIL PROTECTED]
 Date: Thu, 29 Mar 2007 17:24:10 +0100
 
  One of the effects of the recent tidy up of the DECnet routing rules
  code is that we are no longer able to see the difference between reading
  a rule of type FR_ACT_UNREACHABLE returning -ENETUNREACH and simply
  running out of rules to look at, which also returns the same thing.
  
  The DECnet code used to return -ESRCH if it ran out of rules in which
  case the test in dn_route.c (which resulted in DECnet falling back to
  endnode routing in the -ESRCH case) no longer works.
  
  So there seems to be several options to try and solve this: one is to
  change the error return for running out of rules in
  fib_rules.c:fib_rules_lookup() to something else (but then that has a
  knock on effect in the ipv4 code). Another is to add the not found
  error return as a parameter in the struct fib_rules_ops so that both
  protocols can have their preferred error return. Both solutions seem a
  bit messy, so I thought I'd ask for some guidance on this before writing
  a patch,
 
 I think we should be able to return -ESRCH (a more sensible error
 value if you ask me) across the board.
 
 Thomas what do you think?

I agree.
-
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