Wiley.Symbian.OS.Internals.Real.time.Kernel.Programming.Dec.2005.eBook-DDU (779891), страница 58
Текст из файла (страница 58)
Otherwise this isNULL.iSizeSize of committed memory in the chunk. Note that thisdoes not include the gaps in a disconnectedchunk.THE MEMORY MODEL INTERFACEField269DescriptioniMaxSizeThe reserved size of the chunk address region. This isusually the actual size reserved which may be largerthan the requested size, depending on the MMU.iBaseThe virtual address of the first reserved byte in thechunk. This may change over time depending on whichuser-mode process is currently running, and may alsobe specific to a memory context that is not the currentone – so dereferencing this value directly may not yieldthe expected results!iAttributesA set of flags indicating certain properties of the chunk.Some are generic – for example, double ended,disconnected, memory not owned.
Some are memorymodel specific – for example, fixed access (protectedby domain), fixed address, code (on moving model) andaddress allocation and mapping type flags on themultiple model.iStartPosThe offset of the first committed byte in a double-endedchunk. Not used for other chunk types.iControllingOwnerThe process ID of the process that set restrictions onchunk.iRestrictionsSet of flags that control which operations may becarried out on the chunk. For example, this is used toprevent shared chunks from being adjusted byuser-mode software. Shared chunks are described inSection 7.5.3.2.iMapAttrFlags to control how the chunk is mapped into memory.Only used for shared chunks.iDestroyedDfcA DFC that is invoked once the chunk is fully destroyed.Chunk destruction is asynchronous and depends on allreferences to the chunk being released – this enablesthe device that owns the memory mapped by the chunkto know when the mapping has been removed.iChunkTypeThe type of use that the chunk is put to.
This is one ofthe TChunkType values already described.270MEMORY MODELSWe specify the chunk API entirely in terms of offsets from the baseaddress. This is because the base address of a chunk is a virtual address,and thus may change depending on the memory context – in particular,different processes may have a different base address for the same chunk,or the kernel may find a chunk at a different base address than user codedoes. The precise circumstances under which the base address changesdepend on the memory model.We create a chunk with a specified maximum size, which determinesthe maximum size of the address range it covers; a chunk may nevergrow beyond this size. The memory model reserves a suitable regionof virtual address space for the chunk which is at least as large as themaximum size, though it may be larger, depending on the particularMMU of the device.The memory model provides chunk adjust functions which allow thecommitted region within the chunk to be changed in accordance withthe chunk type:Set the end of the committed region of a normal chunk.This will commit or release pages of memory asrequired to achieve the new size.Adjust()AdjustDoubleEnded() Move one or both of the ends of the committed regionof a double-ended chunk.Commit()Commit the pages containing the region specified.
Ifany of the pages are already committed this will fail – soit is advisable to always specify page-aligned offsets.Decommit()Release the pages containing the region specified. Thiswill ignore pages that are not committed withoutreporting an error.Allocate()Allocate and commit a region of the size requested.Optionally allocate a preceding guard region (which isnot committed) and request larger than page-sizealignment.7.3.2 DCodeSegA code segment is responsible for the loaded contents of an executableimage file, either an EXE or a DLL. This will be the relocated code andread-only data, as well as the relocated initial state of writable data, if itis present in the executable. We store this initial writable data in memoryto avoid the need to re-read and relocate this from the executable filewhen initializing additional copies of the writable data section for theTHE MEMORY MODEL INTERFACE271executable.
As Symbian OS does not encourage the use of writable staticdata, this does not result in any significant waste of memory.The code segment may own the memory for the code in different ways,depending on the memory model. In some cases, a single disconnectedchunk manages all the memory for code segments, and in others the codesegment manages the pages of memory directly.As an optimization, code that is part of an XIP ROM does not usuallyhave a code segment object to represent it in the kernel, unless it isdirectly referenced by a DProcess or DLibrary object.Here are the other main responsibilities of code segments:• Recording important information for the code segment, such as thecode and data location, size and run address; the table of exceptionhandlers; the code entry point; the directory of exports and more• Maintaining the record of dependencies it has on other code segments.These are the dependencies that result from importing functions fromother DLLs.
Note that these dependencies can be circular, becausemutual dependency between DLLs is legal. These dependencies areused to determine which code segments should be mapped in orout of a process as a result of a DLL being loaded or unloaded, orto determine when a code segment is unused and can be destroyedentirely• Mapping the code segment into and out of a process address contextwhen DLLs are loaded and unloaded.
How, or if, this happensdepends on how the memory model chooses to allocate and mapcode segments.Chapter 10, The Loader, provides a thorough description of how codesegments are used to manage executable code.It is worth noting that EKA1 does not have a DCodeSeg object. InEKA1, the responsibilities of DCodeSeg were partly in DLibrary classand partly in DChunk. This arrangement suited the processor architecturesand ROM available at the time it was designed. The complete redesignof this area for EKA2 was driven by the desire to exploit the very differentmemory model for ARMv6, and a need for a far more scalable designto manage hundreds of executables loaded from non-XIP Flash. EKA2still has a DLibrary object, but it purely provides the kernel side of theuser-mode RLibrary interface to dynamic code.7.3.3 DProcessWithin the OS, a process is a container of one or more threads (seeChapter 3, Threads, Processes and Libraries) and an instantiation of an272MEMORY MODELSexecutable image file (see Chapter 10, The Loader ).
However, we havealready seen that it is also the owner of a distinct, protected memorycontext. This means that it is concerned with both owning the memorybelonging to the process (or being shared by the process), and also withowning the mapping of that memory into its virtual address space.The memory model must maintain enough information with its processobjects to be able to manage the process address context. This context isused by the memory model in the following situations:• Process context switch. The previous context and protection mustbe removed from the MMU and the new one established. Changing the virtual to physical address map usually requires modifyingone or more MMU registers, and may require invalidation of nowincorrect TLB entries and cache data due to changing the virtual tophysical mapping• Process termination.
The memory model must be able to releaseall memory resources that the process owned or shared and returnthem to the system. Failure to do this would obviously result in slowexhaustion of the system memory and eventual reboot• Inter-process communication – data transfers between processes.When a thread needs to read or write memory belonging to anotherprocess – this included when a kernel thread wishes to read or writeuser-mode memory – the memory model must be able to locate andmap that memory to transfer the data.7.3.4 DThreadAlthough the memory model is concerned with managing the processaddress space, a number of the operations that depend on the implementation of the memory model are logically carried out on threads, and sothese operations are presented as members of the DThread class:AllocateSupervisorStack()FreeSupervisorStack()AllocateUserStack()FreeUserStack()The management of supervisor and user-modethread stacks is memory model dependent.MMU enabled memory models typicallyallocate all thread stacks for a process in asingle disconnected user-mode chunk, withuncommitted guard pages between each stackto catch stack overflow.
Similarly, the kernelallocates all kernel-mode thread stacks in asingle kernel chunk with guard pages betweenthem.THE MEMORY MODEL INTERFACE273ReadDesHeader()RawRead()RawWrite()These support the kernel reading from andwriting to another thread’s user memory. Thesemethods will carry out any necessary checks toensure that the specified ‘‘remote’’ memory ispart of the thread’s user memory address space.They can also check that the ‘‘local’’ memorybuffer is within the executing thread’s usermemory context.This functionality is exposed to drivers via theKern::ThreadDesRead() andKern::ThreadRawRead() set of APIs,which in addition will trap any exceptionscaused by unmapped addresses.The user-mode client/server RMessagePtr2APIs in turn use these for transferring databuffers between a client and server.ExcIpcHandler()This provides the exception handler used inconjunction with the exception trap (see mydiscussion of XTRAP in Chapter 6, Interruptsand Exceptions) as part of the inter-processcopying I mentioned earlier.
This enables anexception caused by providing a faulty remoteaddress to be treated as an error response, butone caused by a faulty local address to betreated as a programming error, that is, a panic.RequestComplete()This is the kernel side of the Symbian OSprogramming patterns that useTRequestStatus,User::WaitForRequest() and activeobjects.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
