blob: d5cba21ceea763304858092da40ad62d5f17cb4a [file] [log] [blame]
// Copyright 2024 The Fuchsia Authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
library fuchsia.sysmem.heap;
// To specify a specific heap, the heap type is specified by a bind string, and
// the heap instance ID is specified by an unsigned 64 bit integer that only
// needs to be unique within the heap type, and only per boot.
//
// For heap types that refer to a singleton heap of that type per device, the
// heap instance ID can be un-set (in FIDL) or set to 0. The heap instance ID
// has no associated bind string - it's just mentioned here for context.
// Heap type bind strings (so far) are of the form
// fuchsia.sysmem.heap[.<namespace>].HEAP_TYPE.<type_name> or
// fuchsia.<vendor|platform>.platform.sysmem.heap[.<namespace>].HEAP_TYPE.<type_name> or
// <vendor>[.<namespace0>].sysmem.heap[.<namespace1>].HEAP_TYPE.<type_name>
//
// A bind string is created by creating a bind library (in any repo) with
// "sysmem.heap" in the library name, defining an enum named HEAP_TYPE with the
// heap types listed as values in the enum. All heap bind strings in the fuchsia
// repo will have "namespace0" empty (consistent with the patterns above under
// fuchsia that lack a "namespace0").
//
// All heap type strings (outside of tests) should include "sysmmem.heap" as
// part of the bind library name, and use "HEAP_TYPE" as the name of the enum.
//
// This allows for distributed allocation of heap type names, while keeping the
// chance of collision low enough, as long as the <vendor>, platform, and
// namespace portions are allocated sensibly. Please no camping on names that
// aren't plausibly yours to camp on.
//
// Some general non-vendor-specific heap types are defined in this file, and
// have the form fuchsia.sysmem.heap.HEAP_TYPE.<type_name>, for example
// fuchsia.sysmem.heap.HEAP_TYPE.SYSTEM_RAM. These types can be used on various
// devices from various vendors.
//
// For some current vendor-specific heap type name definitions, definitions are
// in the fuchsia repo. Because the fuchsia repo requires bind lib names to
// start with "fuchsia", the second form above is used for vendor-specific
// heap types defined in the fuchsia repo. If these heap name definitions later
// move to a different repo in future, they can be renamed to start with
// <vendor> instead (3rd form above is recommended). At runtime a heap type can
// be referenced by more than one name (support for this is currently TODO), to
// allow for soft-transition renames.
// Heap type names that don't conform to the bind string naming scheme or don't
// use a bind lib to define heap type names may break without warning. For
// example, any namespace portion(s) must be lowercase without any whitespace.
// Using this bind string mechanism and specific forms described above to define
// heap type strings is strongly recommended in "steady state", but in some
// temporary situations, it may make sense to temporarily specify a bind string
// that is just a string, without reference to a bind library or its generated
// code.
//
// For example this can make sense if a heap type name is being changed in a
// non-breaking way. At some stage during such a rename, a heap implementation
// may want to continue registering/accepting a deprecated + removed (but still
// reserved) heap name, without that name being a currently-defined bind string.
// This way, binaries wouldn't break, but on the next build of participant code,
// the build would fail when the participant tries to use the removed name (from
// the bind lib generated code), and the fix can be made fairly obvious by
// leaving a helpful and searchable comment in the .bind lib file that used to
// have the now-removed name.
// We don't define a heap ID in this bind lib. The fuchsia.sysmem2.Heap FIDL
// table has an "id" field for the heap ID. Heap IDs are typically either 0 for
// a heap type corresponding to a singleton heap, or dynamically assigned and
// discovered per-boot. Most cases involving fixed heap IDs would make more
// sense as separate heap types, or as a logical single heap that uses multiple
// separate chunks of space internally.
//
// In the event that fixed heap IDs make the most sense for a future heap type,
// the bind lib that defines the heap types for that platform can choose to
// define fixed heap IDs in that bind lib as well. The recommended name for that
// uint or uint64 is "HEAP_ID". Using a uint64 is recommended if supported in
// bind libs by then, but uint can work fine for fixed heap IDs. The heap ID is
// a uint64 in FIDL, so a uint(32) in a bind lib can get zero-extended to uint64
// at point of use.
enum HEAP_TYPE {
// Generic RAM.
//
// This is the default when no participant sets
// fuchsia.sysmem2.BufferMemoryConstraints.permitted_heaps.
//
// Depending on device configuration, this heap can be capable of allocating
// both non-physically-contiguous and physically-contiguous buffers.
//
// Currently this is a singleton, with a single logical SYSTEM_RAM heap with
// id 0.
//
// Typically the SYSTEM_RAM heap is not usable for allocating when
// secure_required true. An initiator specifying secure_required true can
// permit any is_secure true heap by leaving permitted_heaps un-set and
// setting inaccessible_domain_supported to true. This requires at least one
// participant to list a specific is_secure true heap. Currently all
// is_secure true heaps are vendor-specific, with corresponding bind strings
// defined in separate vendor-specific bind libs, with their own separate
// HEAP_TYPE enums.
SYSTEM_RAM,
// Heap used for display framebuffer. This is used by display drivers
// limited to a single framebuffer located at a specific physical address.
// The framebuffer heap makes it possible to create buffer collections for
// the framebuffer and enables sysmem support in these drivers.
//
// Currently this is a singleton, with a single logical FRAMEBUFFER heap
// with id 0.
FRAMEBUFFER,
};