[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL1RGDV-oYkNwQQUkAuUEHTH=HbmLk6Kv7JRnJ3XxN1DMNzLNQ@mail.gmail.com>
Date: Mon, 5 Mar 2012 12:34:17 -0800
From: Roland Dreier <roland@...estorage.com>
To: "Hefty, Sean" <sean.hefty@...el.com>,
David Miller <davem@...emloft.net>
Cc: "linux-rdma (linux-rdma@...r.kernel.org)"
<linux-rdma@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH 1/25 v2] rdma/cm: define native IB address
On Mon, Feb 27, 2012 at 2:22 PM, Hefty, Sean <sean.hefty@...el.com> wrote:
>> > --- a/include/linux/socket.h
>> > +++ b/include/linux/socket.h
>> > @@ -184,6 +184,7 @@ struct ucred {
>> > #define AF_PPPOX 24 /* PPPoX sockets */
>> > #define AF_WANPIPE 25 /* Wanpipe API Sockets */
>> > #define AF_LLC 26 /* Linux LLC */
>> > +#define AF_IB 27 /* Native InfiniBand address */
>> > #define AF_CAN 29 /* Controller Area Network */
>> > #define AF_TIPC 30 /* TIPC sockets */
>> > #define AF_BLUETOOTH 31 /* Bluetooth sockets */
>> > @@ -227,6 +228,7 @@ struct ucred {
>> > #define PF_PPPOX AF_PPPOX
>> > #define PF_WANPIPE AF_WANPIPE
>> > #define PF_LLC AF_LLC
>> > +#define PF_IB AF_IB
>> > #define PF_CAN AF_CAN
>> > #define PF_TIPC AF_TIPC
>> > #define PF_BLUETOOTH AF_BLUETOOTH
>>
>> Has this been run by the networking community? Are they OK with this
>> assignment?
>
> I did copy netdev on the original submissions, but I don't remember any explicit ack or nack.
David, any feeling yay or nay about adding these?
Is the kernel the final arbiter of AF_xxx / PF_xxx assignments, or
is there anything else we have to worry about?
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists