[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200514193527.GB16070@bombadil.infradead.org>
Date: Thu, 14 May 2020 12:35:27 -0700
From: Matthew Wilcox <willy@...radead.org>
To: David Laight <David.Laight@...lab.com>
Cc: 'Christoph Hellwig' <hch@....de>,
Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
"linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
Eric Dumazet <edumazet@...gle.com>,
"target-devel@...r.kernel.org" <target-devel@...r.kernel.org>,
"linux-afs@...ts.infradead.org" <linux-afs@...ts.infradead.org>,
"drbd-dev@...ts.linbit.com" <drbd-dev@...ts.linbit.com>,
"linux-cifs@...r.kernel.org" <linux-cifs@...r.kernel.org>,
"rds-devel@....oracle.com" <rds-devel@....oracle.com>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"cluster-devel@...hat.com" <cluster-devel@...hat.com>,
Alexey Kuznetsov <kuznet@....inr.ac.ru>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
'Joe Perches' <joe@...ches.com>,
Jakub Kicinski <kuba@...nel.org>,
"ceph-devel@...r.kernel.org" <ceph-devel@...r.kernel.org>,
"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
Neil Horman <nhorman@...driver.com>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Vlad Yasevich <vyasevich@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Jon Maloy <jmaloy@...hat.com>,
"linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>,
Ying Xue <ying.xue@...driver.com>,
"David S. Miller" <davem@...emloft.net>,
"ocfs2-devel@....oracle.com" <ocfs2-devel@....oracle.com>
Subject: Re: [Ocfs2-devel] remove kernel_setsockopt and kernel_getsockopt
On Thu, May 14, 2020 at 11:11:34AM +0000, David Laight wrote:
> 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.
Oh, good point, we'll change the policy for all modules and make every
interface in the kernel stable from now on to cater to your special case.
Powered by blists - more mailing lists