Ideally, only labeling should occur on device policy, as everything should be able to be slotted into some generalization in the base policy. Although, not sure how dev specific daemons can be slotted like this, but I am sure they could be generalized a bit more rather than having a type for everything. Obviously we will lose fine grained control, but have a much more generic model that OEMs and others won't need to customize as much.
Bill On Tue, May 21, 2013 at 1:30 PM, William Roberts <[email protected]>wrote: > Yeah any of the specific types, like kgsl (guilty) or ion should be > generalized... > > pmem and ion could probably share a type etc... and continuing this for > everything else that fits this. > > > On Tue, May 21, 2013 at 1:21 PM, Stephen Smalley <[email protected]>wrote: > >> On 05/21/2013 04:13 PM, Peck, Michael A wrote: >> >>> Hi Stephen, >>> >>> I'm wondering what the reasoning is for the sysfs_devices_system_cpu >>> type and policies to only be in grouper (device/asus/grouper/sepolicy) and >>> not global? >>> >>> sources/android/cpufeatures/**cpu-features.c in the Android NDK has a >>> get_cpu_count function that reads from the /sys/devices/system/cpu/**present >>> and /sys/devices/system/cpu/**possible files. >>> Some related discussion here: https://code.google.com/p/** >>> android/issues/detail?id=26490<https://code.google.com/p/android/issues/detail?id=26490> >>> >> >> Probably no good reason other than we didn't encounter it on the other >> devices. >> >> I have a general todo item of needing to purge external/sepolicy of all >> device-specific definitions (some of which originated before we supported >> the per-device policy files) and finding any bits from the current >> per-device policies that ought to be generalized and brought into >> external/sepolicy. >> >> >> >> >> >> -- >> This message was distributed to subscribers of the seandroid-list mailing >> list. >> If you no longer wish to subscribe, send mail to [email protected] >> the words "unsubscribe seandroid-list" without quotes as the message. >> > > > > -- > Respectfully, > > William C Roberts > > -- Respectfully, William C Roberts
