On 09/28/2012 01:18 PM, William Roberts wrote: > On Fri, Sep 28, 2012 at 10:03 AM, rpcraig <rpcr...@tycho.ncsc.mil> wrote: >> On 09/26/2012 03:00 PM, William Roberts wrote: >>> Just to make sure I understand, if I do this in my product makefile: >>> >>> PRODUCT_SEPOLICY_REPLACE := genfs_contexts >>> PRODUCT_SEPOLICY_UNION := te_macros >>> >>> The resulting policy will use >>> device/mfr/product/sepolicy/genfs_contexts and it will use a >>> concatenation of external/sepolicy/te_macros and >>> device/mfr/product/sepolicy/te_macros? >>> >>> Everything is running through M4, so I can still use the include >>> mechanism to include from a parent common folder. However, it would be >>> nice to have: >>> >>> PRODUCT_SEPOLICY_COMMON := common/dir >>> >>> Where I can specify common files... >>> >>> So if I did something like: >>> >>> PRODUCT_SEPOLICY_COMMON := device/mfr/prod_common/sepolicy/te_macros >>> PRODUCT_SEPOLICY_UNION := te_macros >>> The resulting te macros would be a concatenation of >>> external/sepolicy/te_macros + >>> device/mfr/prod_common/sepolicy/te_macros + >>> device/mfr/prod/sepolicy/te_macros essentially doing the #include >>> without a #include... >>> >>> This way I don't have to chase down include hierarchies. >>> >>> >>> >>> >> Let me make sure I get this straight before I release the next patch as >> I looked a second time at your request. Are you asking for a variable >> that allows you to specify a common directory (PRODUCT_SEPOLICY_COMMON >> := common/dir) from which either unions or override files can exists? >> Those files would then be described in the UNION and REPLACE variables >> like the rest if wanted. I ask because from next example you give, you >> effectively have two variables that specify sepolicy files to union. You >> defined PRODUCT_SEPOLICY_COMMON as a common directory then you reset it >> to a file. > Oops, I meant directory with PRODUCT_SEPOLICY_COMMON and then if you > specify a union on file X, external/sepolicy/X device/sepolicy/X and > common/policy/X would be in the resulting set. Maybe a more generic > name for it would be PRODUCT_SEPOLICY_DIRS where you can define a list > of directories to search for sepolicy dirs... >
That's what I thought you meant. Hmmmm. If we allow a list to be specified for PRODUCT_SEPOLICY_DIRS then do we really need to enforce that there is an sepolicy subdir in all products? So in effect, someone would have to create a PRODUCT_SEPOLICY_DIRS list and the UNION and REPLACE vars. Thoughts? -- This message was distributed to subscribers of the seandroid-list mailing list. If you no longer wish to subscribe, send mail to majord...@tycho.nsa.gov with the words "unsubscribe seandroid-list" without quotes as the message.
