[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c2034daa0a23454abb5e5c5714807735@AcuMS.aculab.com>
Date: Thu, 14 May 2020 11:11:34 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Christoph Hellwig' <hch@....de>
CC: 'Joe Perches' <joe@...ches.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Eric Dumazet <edumazet@...gle.com>,
"Alexey Kuznetsov" <kuznet@....inr.ac.ru>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
Vlad Yasevich <vyasevich@...il.com>,
Neil Horman <nhorman@...driver.com>,
Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
Jon Maloy <jmaloy@...hat.com>,
Ying Xue <ying.xue@...driver.com>,
"drbd-dev@...ts.linbit.com" <drbd-dev@...ts.linbit.com>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
"target-devel@...r.kernel.org" <target-devel@...r.kernel.org>,
"linux-afs@...ts.infradead.org" <linux-afs@...ts.infradead.org>,
"linux-cifs@...r.kernel.org" <linux-cifs@...r.kernel.org>,
"cluster-devel@...hat.com" <cluster-devel@...hat.com>,
"ocfs2-devel@....oracle.com" <ocfs2-devel@....oracle.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>,
"ceph-devel@...r.kernel.org" <ceph-devel@...r.kernel.org>,
"rds-devel@....oracle.com" <rds-devel@....oracle.com>,
"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>
Subject: RE: remove kernel_setsockopt and kernel_getsockopt
From: 'Christoph Hellwig'
> Sent: 14 May 2020 11:35
> On Thu, May 14, 2020 at 10:26:41AM +0000, David Laight wrote:
> > From: Christoph Hellwig
> > > Only for those were we have users, and all those are covered.
> >
> > What do we tell all our users when our kernel SCTP code
> > no longer works?
>
> We only care about in-tree modules, just like for every other interface
> in the kernel.
Even if our management agreed to release the code and the code
layout matched the kernel guidelines you still wouldn't want
two large drivers that implement telephony functionality
for hardware that very few people actually have.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists