On Fri, Sep 16, 2016 at 11:44 AM, Janis Danisevskis <jdanis@xxxxxxxxxxx> 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 consideration. <snip> _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
