Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> writes: > > --- net-2.6.24.orig/include/linux/if_arp.h 2007-10-02 12:10:51.000000000 > > +0200 > > +++ net-2.6.24/include/linux/if_arp.h 2007-10-02 12:11:01.000000000 > > +0200 > > @@ -52,6 +52,7 @@ > > #define ARPHRD_ROSE 270 > > #define ARPHRD_X25 271 /* CCITT X.25 */ > > #define ARPHRD_HWX25 272 /* Boards with X.25 in firmware > > */ > > +#define ARPHRD_CAN 280 /* Controller Area Network */ > > Is 280 used in other OS? Just curious as why not using 273
When we first implemented PF_CAN a couple of years ago, we wanted to avoid a clash with other ARPHRD_* defines which might be added, so we skipped some numbers after the last used one. I don't care what number ARPHRD_CAN is, we can use 273. > > --- net-2.6.24.orig/include/linux/socket.h 2007-10-02 12:10:51.000000000 > > +0200 > > +++ net-2.6.24/include/linux/socket.h 2007-10-02 12:11:01.000000000 > > +0200 > > @@ -185,6 +185,7 @@ > > #define AF_PPPOX 24 /* PPPoX sockets */ > > #define AF_WANPIPE 25 /* Wanpipe API Sockets */ > > #define AF_LLC 26 /* Linux LLC */ > > +#define AF_CAN 29 /* Controller Area Network */ > > Ditto > > > #define AF_TIPC 30 /* TIPC sockets */ > > #define AF_BLUETOOTH 31 /* Bluetooth sockets */ > > #define AF_IUCV 32 /* IUCV sockets */ For the same reason as above, we didn't use 27, but the last unused without modifying AF_MAX. First, we had AF_CAN == 30, then TIPC used that number and we changed AF_CAN to 29. Changing again would mean an ABI change and would break user apps. If there is a pressing reason I wouldn't mind personally, but it would probably upset quite a number of users of our code. It seems common now to allocate these numbers from the top in decreasing order. urs - 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
