Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757750AbeAIILM (ORCPT + 1 other); Tue, 9 Jan 2018 03:11:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55694 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757707AbeAIILL (ORCPT ); Tue, 9 Jan 2018 03:11:11 -0500 Subject: Re: [PATCH 09/11] powerpc/64s: Allow control of RFI flush via sysfs To: Greg KH References: <20180108165453.26066-1-mpe@ellerman.id.au> <20180108165453.26066-9-mpe@ellerman.id.au> <87y3l880js.fsf@concordia.ellerman.id.au> <20180109080527.GA32120@kroah.com> Cc: Michael Ellerman , Thomas Gleixner , mikey@neuling.org, Peter Zijlstra , LKML , npiggin@gmail.com, linuxppc-dev@ozlabs.org, oohall@gmail.com, Anton Blanchard , Paul Mackerras From: Jon Masters Message-ID: Date: Tue, 9 Jan 2018 03:11:08 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20180109080527.GA32120@kroah.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 09 Jan 2018 08:11:11 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 01/09/2018 03:05 AM, Greg KH wrote: > On Tue, Jan 09, 2018 at 01:06:23AM -0500, Jon Masters wrote: >> Knowing that the IBM team was going to post with this sysfs interface, >> our trees contain the rfi_flush file. I mentioned it to some folks on >> this end (because we know we don't want to add things in sysfs >> generally, debugfs is a good substitute, per Andrea, and I raised this >> with him yesterday as a concern in the backport here) but in the end it >> seemed reasonable to pull this in because it was what got posted, and as >> Michael says, it's gone into other distro kernels beyond just ours. > > What distro kernels end up enabling does not really reflect on what we > end up doing in mainline. The api for this should NOT be arch-specific > if at all possible, that way lies madness. Do you want to write > userspace tools to handle the 60+ different arch implementations? > > Don't let the fragmentation problems of the period in which no one was > allowed to talk to each other, result in a unchangable mess, that would > be insane. Totally fine :) Just saying we tried to do reasonable things with what we had. Whatever happens upstream in the end is, of course, what we'll make sure fits into updates that go into the likes of RHEL. Jon. -- Computer Architect | Sent from my Fedora powered laptop