[Linux-decnet-user] RFC: The loopback device in 2.5 kernels

[Steven W. <st...@gw...>]

Hi,

Here is an RFC on a rather unusual topic... I've been looking into the
requests recently to make the DECnet addresses of devices more easily
configurable. I've currently got a work-in-progress patch with the
following changes from 2.5.36:

 o The autoconfig function for ethernet devices has been changed so that any
   ethernet device with hiord in its MAC address will gain a DECnet address to
   match when the device is brought up.

 o Any ethernet device which has a DECnet address added to it, will also
   add the correct (unicast) MAC address to its multicast list in the case
   that the MAC address isn't the same as the device MAC address.

 o The output packet code has been tweeked to take account of these changes
   by ensuring that it uses the correct source address for packets.

 o The hello code has been tweeked so that every configured address for an
   interface will result in a hello message being sent out (with the
   correct contents).

Currently the decision about sending router or endnode hellos is left as
a "per interface" option. Clearly it seems to make sense to move this
toward a "per address" option in the future, but I want to think a bit
more about the interactions between the different addresses on an interface
before I do that.

So the RFC in this case relates to two things, namely the only two places
in which the decnet_address variable as configured on the kernel command
line is still used.

 1. In autoconfiguration of the loopback device. There must be a better way
    of doing this. I know Linux is unique in this slightly odd method of
    using a loopback device for DECnet, but it does have the advantage of
    being able to reuse a lot of the TCP/IP code for routing.

    One solution might be to autoconfigure the loopback device with every
    address which is added to other interfaces in the system. It sounds
    easy, but will in fact cause a fairly large code change.

    Another solution is just to ignore it. We could force people to add
    the addresses to the loopback device manually using iproute2.

    So this is the main area where I'm asking for ideas of how we should
    proceed.

 2. In autobind, the decnet_address variable is used to give us a default
    local address to bind to. We could do something really simple, such as
    bind to the first address on the loopback device by default, or we
    could leave the decnet_address variable for just this one purpose.
    It would be nice if we could in fact bind to something like DNADDR_ANY
    for example so that we can make the source address decision later. This
    would need the fixing of prefsrc in the routing code though.

    Again all ideas are welcome.

So I hope this makes some kind of sense :-) Let me know if you have any
questions in case I've not explained things very well. I hope to come up
with a patch in the next few days for testing and eventual submission to
the 2.5 kernel series. I'm not intending to back port any part of this
work to the 2.4 kernels at least until this is working and tested in 2.5
and only then if there is a demand for it and if I can ensure its 100%
backward compatible.

Steve.