Wiley.Symbian.OS.Internals.Real.time.Kernel.Programming.Dec.2005.eBook-DDU (779891), страница 71
Текст из файла (страница 71)
This is the case for the file system ELFFS.FSYshown in the diagram.However, it is possible to add an extension layer between the filesystem and the TBusLocalDrive object for a particular drive. Theseextension layers are known as file server extensions and they are executeduser-side. They provide a way to add functionality to a standard file systemthat is only required for a certain type of drive. They are built as a separatecomponent, and have the file extension .FXT.
The file server providesAPIs to install an extension and then associate it with a particular drive.For example, as you will see later, a special translation layer is neededto run a FAT file system over a NAND Flash device. Since this layer isnot required when using FAT on a RAM disk or a MultiMediaCard, itwould not be appropriate to add this functionality to the FAT file systemcomponent itself.
Instead, we can implement the Flash translation layer(FTL) as a file server extension (NANDFTL.FXT), and use it only on NANDlocal drives.The file server also supports file server plug-ins. Built as separatecomponents, with the file extension .PXT, the plug-ins register with thefile server and are then able to intercept requests from any file serverclients. Plug-ins can be used to support virus scanning, file compressionand file encryption software. The plug-in can set a filter for particulartypes of request (for example file open) and for requests involving aparticular path or drive.
When a request is intercepted, the plug-in isgiven the opportunity to issue its own file server requests using thenormal F32 client API (so it can scan the file being opened, for example)before deciding on whether to allow the original request to resume.Alternatively, the plug-in can fail the request. The file server allows morethan one plug-in to register at the same time. It maintains a strict policyon the order in which it notifies the plug-ins, should their request filterscoincide. So, for example, if both a virus scanner and a file-compressionplug-in were installed, then the compression software would have todecompress a file before the virus scanner scanned it.9.1.2.1 Drive lettersThe file server supports a maximum of 26 drives, each identified (inDOS-like convention) by a different drive letter (A: to Z:).
As I said earlier,the main ROM drive is always designated as the last drive, Z:.338THE FILE SERVERApart from on the emulator, sixteen of the drives (C: to R:) are normallyreserved as local drives – that is, they are available for mounting driveson media devices that are located within the phone. Of these, C: is alwaysdesignated as the main user data drive, and any removable media deviceis generally designated as D: or E:.The remaining 9 drives are available as remote drives, or substituted drives.9.1.2.2 F32 on the Symbian OS emulatorOn the Symbian OS emulator, any of the 26 drives can be used for mapping to native drives – that is, mapping directories on the host machine’sfile system to drives on the Symbian OS file server.
We do this by using anemulator-specific Symbian OS file system, which converts the SymbianOS file server calls into calls onto the host operating system’s file system.There are two default emulator drives – Z:, which represents the targetphone’s ROM, and C:, which represents the phone’s main user-datastorage drive. However, by editing the emulator configuration file (usually EPOC.INI), you can reconfigure these drives to map to alternativelocations, and you can map additional native drives.The emulator is generally configured with only these native drivesenabled.
However, you can enable additional drives that use emulatorbuilds of the file systems that are used on the actual hardware platforms – for example the Symbian OS FAT file system. You can do thiseither by editing the emulator configuration file or by configuring ESTART(see Section 13.3.1 and Chapter 16, Boot Processes). This can be a usefulaid when developing a new file system or debugging an existing one.Apart from the ROM file system, all the standard Symbian OS file systemscan be used in this way. The majority of the source code for the emulatorbuilds of these file systems is the same as that used for the hardware platforms.
Indeed, the same applies for the logical layer of the local mediasub-system. However, these drives use emulator specific media driverswhich normally read and write to a binary file on the host machine toemulate the memory area of the disk rather than accessing any mediahardware directly.9.1.2.3 F32 startupThe file server loads and runs early in the Symbian OS boot sequence,immediately after the kernel has been booted.
Obviously, we need aspecial loading mechanism since at this stage neither the loader nor theROM file system is available. We use a special statement in the ROMimage specification (that is, the ROM obey file), to designate the fileserver as the secondary process in the system. The result is that the mainROM header holds the address of its image in ROM to allow a kernelTHE FILE SERVER CLIENT API339extension to start it.
(Once the file server is running, the loader can startall the other executables in the system.)Once the file server is loaded, its main thread runs and installs theROM file system. Again, without the loader and the ROM drive, this can’tbe done in the same way as a normal file system – this is why we buildthe ROM file system into the file server executable, rather than havingit as a separate library. Next, the file server starts the loader thread, andthen an F32 startup thread.The startup thread, which is a separate thread to allow it to use thefile server client API, now runs and continues file server initialization.
Itinitializes the local media sub-system and then executes ESTART.EXEfrom Z: before exiting.ESTART completes the file server initialization process, performingoperations such as loading and mounting the file systems. Finally itinitiates the startup of the rest of Symbian OS. To do this, it usuallylaunches SYSSTART.EXE, the system startup process, but if this is notpresent, it launches the window server, EWSRV.EXE, instead. Developerswho are creating a new phone platform usually customize ESTART toperform platform specific initialization of the file server or other low-levelcomponents. In Chapter 16, Boot Processes, I will cover system boot inmore depth.9.1.2.4 The text shellWithin the F32 source tree, we have implemented a simple text shell(ESHELL.EXE), which presents the user with a DOS-like commandprompt.
The shell can be used for running console-mode test programsin a minimal Symbian OS configuration that includes only E32 and F32components. We also provide a minimal window server (EWSRV.EXE) inthe E32 source tree too.9.2 The file server client APIWe have seen that the file server allows clients to access files, directoriesand drives on the Symbian OS phone. Client programs access the F32services by linking to EFSRV.DLL, which provides the client API definedin f32file.h.STDLIB (the Symbian OS implementation of the standard C library)uses this API to add a thin mapping layer to implement POSIX-compliantfile services.
However, in this section I will describe only the file serverclient API, as this is the most common way for system applications toaccess file services. In this book, I will provide only an overview of the340THE FILE SERVERclient API. For more detail, the reader should refer to Symbian OS C++for Mobile Phones.1Not surprisingly, most file services involve communication with the fileserver. (Only a small number are handled client-side, an example beingthe services provided by the TParseBase-derived file name parsingclasses – see Section 9.2.4.)9.2.1 RFs class – the file server sessionAll access from client to file server takes place via a file server session.A session is established thus: the client creates an instance of the fileserver session class, RFs, and connects it to the server using the methodRFs::Connect().
Clients may have more than one session open simultaneously. The kernel assembles the data for session-based requests intoa message and passes a message handle to the server. The file serverprocesses the message and passes the result back to the client.The file server’s clients are normally in different processes to the fileserver – exceptions are the Symbian OS loader, the F32 startup thread(which I described in Section 9.1.2.3), and file server plug-ins. Because ofthis, most requests on the file server involve the kernel context switchingbetween processes, which can be an expensive operation. However, thefile server is a fixed process, which reduces the impact of the contextswitch considerably (see Section 7.4.1.3).The file server doesn’t use client-side buffering. This is because theway in which its services are used and the types and formats of files itmanages are so varied that there aren’t any situations in which this couldbe consistently beneficial.
Instead, higher-level Symbian OS components(such as STORE) implement techniques to minimize the number of callsthey make on the file server.We associate a current path, including a drive letter, with every fileserver session. Only one path is supported per session. The file serverinitializes the path when the client connects the RFs object, and changesit only as the client directs.Many of F32’s services are provided by the RFs class itself. Theseinclude the following groups of services:• Drive and volume information. Examples include:– DriveList() to get a list of the available drives– Volume() to get volume information for a formatted device• Operations on directories and their entries. Examples include:– Entry() to get the entry details of a file or directory1Symbian OS C++ for Mobile Phones: Professional Development on ConstrainedDevices, by Richard Harrison.
Symbian Press.THE FILE SERVER CLIENT API341– GetDir() to get a filtered list of a directory’s contents– MkDir() to create a directory• Change notification. Examples include:– NotifyChange() to request notification of changes to files ordirectories– NotifyDiskSpace() to request notification when the free diskspace on a drive crosses a specified threshold value• File name parsing. Examples include:– Parse() to parse a filename specification• System functions concerning the state of a file system. Examplesinclude:– CheckDisk() to check the integrity of the specified drive– ScanDrive() to correct errors due to unexpected power downof the phone• Management of drives and file systems.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
