On Fri, Sep 16, 2016 at 11:44 AM, Janis Danisevskis <jda...@android.com> wrote:
> I don't really care much about the behavior of sefcontext_compile. I just
> thought making the default behavior the safest would be the best option.
> Before android is using it, I will have to sync the (now modified and
> improved - thank you) patches back into AOSP, which I intend to do. I have
> some benchmarks measuring load and lookup time for file contexts. I am eager
> to review and benchmark William's patches and explore a bit myself. And once
> all options are on the table I can make a case for the fastest solution to
> make it into Android.

+ More Google dudes so they see this.

This is where Android's fork is a PITA. My current TODO list looks like this:
1. Get process_file cleanups up streamed (in progress)
2. Get performance improvements up streamed (I have things local, they
need more work)
3. Rectify the Android/Upstream fork.

For two, I have a UDOO ARM board I was going to add into my performance testing,
since it will run a debian distro I can just use upstream libselinux
and compile checkfc or something
for it. I was going to use that to see if theirs an architectura delta
between arm and x86 with the
performance improvements. All my numbers are only off of an x86 platform.

For three, ideall to me, for phase I this looks like having usptream +
android.c and android.h files.
This way for updating, we can merge, with no conflicts as all android
changes will be confined to
those two files. Ill update upstream to have a method to kill unused
interfaces in a graceful way
as well as fixup android.c/android.h for anything that has been moved
into upstream already,
like the work Richard did with digest files.

After 3, then we can trivially test item 2 on an Android platform,
giving us solid, real world android numbers
and getting us closer to unification.

Does anyone have any objections, concerns on this list, let me know so
I can take them into

Seandroid-list mailing list
To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
To get help, send an email containing "help" to 

Reply via email to