On 03/07/2016 12:09 PM, David Miller wrote:
From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
Date: Mon, 7 Mar 2016 11:04:38 -0700
On 03/07/2016 09:56 AM, David Miller wrote:
From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
Date: Mon, 7 Mar 2016 08:07:53 -0700
PR_GET_SPARC_ADICAPS
Put this into a new ELF auxiliary vector entry via ARCH_DLINFO.
So now all that's left is supposedly the TAG stuff, please explain
that to me so I can direct you to the correct existing interface to
provide that as well.
Really, try to avoid prtctl, it's poorly typed and almost worse than
ioctl().
The two remaining operations I am looking at are:
1. Is PSTATE.mcde bit set for the process? PR_SET_SPARC_ADI provides
this in its return value in the patch I sent.
Unnecessary. If any ADI mappings exist then mcde is set, otherwise it is
clear. This is internal state and the application has no need to every
set nor query it.
It is implicit from the mprotect() calls the user makes to enable ADI
regions.
2. Is TTE.mcd set for a given virtual address? PR_GET_SPARC_ADI_STATUS
provides this function in the patch I sent.
Again, implied by the mprotect() calls.
Hi Dave,
I agree with your point of view. PSTATE.mcde and TTE.mcd are set in
response to request from userspace. If userspace asked for them to be
set, they already know but it was the database guys that asked for these
two functions and they are the primary customers for the ADI feature. I
am not crazy about this idea since this extends the mprotect API even
further but would you consider using the return value from mprotect to
indicate if PSTATE.mcde or TTE.mcd were already set on the given address?
Thanks,
Khalid
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
