[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH v2 2/3] utils: Add cpuinfo helper to fetch /

From: Catalin Marinas
Subject: Re: [Qemu-devel] [RFC PATCH v2 2/3] utils: Add cpuinfo helper to fetch /proc/cpuinfo
Date: Mon, 9 May 2016 13:44:11 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

On Mon, May 09, 2016 at 12:21:08PM +0100, Peter Maydell wrote:
> On 9 May 2016 at 11:59, Suzuki K Poulose <address@hidden> wrote:
> > Well, we have been waiting for a use case, like this, before we merge
> > the series.
> This isn't a great strategy for moving people away from things
> you'd like them to avoid like parsing /proc/cpuinfo, because typically
> userspace app writers are not very interested in coding to facilities
> which don't exist yet, and will prefer to make do with what's actually
> present in the kernel today... You need to provide the improved API,
> and then it needs to get out into kernel versions in distros and
> otherwise, and only then are you likely to get app developers who
> will start to say "this is useful".

The problem is that the way kernel people think the API may be improved
does not always match the use-cases required by app writers. One example
here is exposing MIDR via MRS emulation, we know there are problems with
big.LITTLE and the only clear answer I got so far is that we ignore such
configurations. We don't even have a way to tell user space that this is
a heterogeneous CPU configuration, unless we add another HWCAP bit
specifically for this (or the opposite: HWCAP_HOMOGENEOUS_CPUS).

That said, I'm perfectly fine with exposing:

                                                        \- midr
                                                        \- revidr

I had the wrong impression that we already merged this part but Suzuki
just pointed out to me that it's not.

I think our 4.7-rc1 tree is pretty much frozen to new features now,
though the sysfs patch is relatively small (I'll let Will comment):


The MRS emulation, we should restart the discussion around big.LITTLE
implications and make a decision one way or another by the 4.8 merging


reply via email to

[Prev in Thread] Current Thread [Next in Thread]