Wiley.Symbian.OS.Internals.Real.time.Kernel.Programming.Dec.2005.eBook-DDU (779891), страница 77
Текст из файла (страница 77)
Code on non-XIP media first has to be copiedinto RAM for execution.It is possible for developers to implement their own file system. Normallythey would then customize ESTART to load and mount this file systemduring file server startup. I describe the necessary APIs in Section 9.4.1.6.9.4.1File system APIAs I mentioned in Section 9.3.3.3, a loadable file system is a polymorphicDLL providing plug-in functionality to the file server by implementing thepredefined file system interface classes, which are abstract classes. Eachfile system implements the API by defining and implementing concreteclasses derived from each abstract class.File systems are dynamically loaded by the file server at runtime – anew one can be added and mounted on a drive without the need to restartthe server or interrupt any connected file server sessions.
File systemscontain a single exported function, which the file server calls when thefile system is added to it. This export is a factory function that returnsa pointer to a new file system object – an instance of a CFileSystemderived class. The CFileSystem-derived class is itself a factory class forcreating each of the other file system objects. Having called this export,the server is able to call all other file system functions through the vtablemechanism.The file system API is defined in f32fsys.h. In the following sections,I will discuss the classes of which it is comprised.9.4.1.1 The CFileSystem classThis is a factory class, which allocates instances of each of the otherobjects that form the file system API: CMountCB, CFileCB, CDirCB andCFormatCB.
The file server has only a single CFileSystem instancefor each loaded file system – even when that file system is mounted on anumber of drives.9.4.1.2 The CMountCB classThis class, which I introduced in Section 9.3.3.2, is the abstraction of avolume. The file server creates an instance of CMountCB for each volumeintroduced into the system.The functionality that the file system supplies through this class roughlycorresponds to that contained within the RFs class. So, taking as anexample the method RFs::MkDir() to make a directory, we find thatprogram flow moves from this client function into TDrive::MkDir()366THE FILE SERVERin the file server and then on to CFatMountCB::MkDirL() in the FATfile system (FAT.FSY).
Here is another example:Client DLLFile serverFAT.FSYRFs::Rename() → TDrive::Rename() → CFatMountCB::RenameL()9.4.1.3 The CFileCB classThis class represents an open file. The functionality this class suppliesroughly corresponds to the methods contained in the RFile class. Again,let’s follow the program flow using the FAT.FSY as an example:Client DLLFile serverFAT.FSYRFile::Read() → CFileShare class → CFatFileCB::ReadL()The file server has a single object container, which references everyCFileCB object, across all the drives in the system.9.4.1.4 The CDirCB classThis class represents the contents of an open directory.
This suppliesfunctionality corresponding to the methods contained in the RDir class.Again, the file server has a single object container that references everyCDirCB object across all the drives in the system.9.4.1.5 The CFormatCB classThis class represents a format operation.9.4.1.6 Loading and mounting a file systemWe add file systems to the file server by calling the client method:TInt RFs::AddFileSystem(const TDesC& aFileName) constThe argument aFileName specifies the name of the FSY component tobe loaded. As I mentioned in Section 9.1.2.3, ESTART normally doesfile-system loading during file server startup.Once it has been successfully added, a file system can be mounted ona particular drive using the method:TInt RFs::MountFileSystem(const TDesC& aFileSystemName, TInt aDrive) constFILE SYSTEMS367In this method, aFileSystemName is the object name of the file systemand aDrive is the drive on which it is to be mounted.The EKA1 version of the file server requires a nominated default filesystem, which must be called ELOCAL.FSY.
The EKA2 version of thefile server places no such restriction on the naming of file systems, or inrequiring a default file system.If you are developing file systems, there are two methods availablewhich are useful for debugging:TInt RFs::ControlIo(TInt aDrive,TInt,TAny*,TAny*)This is a general-purpose method that provides a mechanism forpassing information to and from the file system on a specified drive.
Theargument aDrive specifies the drive number, but the assignment of thelast three arguments is file system specific.Additionally, the following method can be used to request asynchronous notification of a file system specific event:void RFs::DebugNotify(TInt aDrive,TUint aNotifyType,TRequestStatus& aStat)The argument aDrive specifies the target drive number, aNotifyType, specifies the event, and aStat is a reference to a request statusobject that is signaled when the event occurs.To trigger the notifier, the file system calls the following method, whichis exported by the file server:void DebugNotifySessions(TInt aFunction,TInt aDrive)The argument aFunction specifies the event that has occurred andaDrive indicates the drive on which this has occurred.So for example, if when testing, it is required for the test programto issue a particular request when a certain condition occurs in a filesystem then using DebugNotifySessions(), the file system can beconfigured to complete a pending debug notification request wheneverthe condition occurs.All these methods are only available in debug builds.9.4.2 The log Flash file system (LFFS)I introduced Flash memory in Section 9.1.1, where I mentioned thedifferent types of Flash that we support in Symbian OS.
We designed thelog Flash file system to enable user-data storage on NOR Flash devices.368THE FILE SERVER9.4.2.1 NOR Flash characteristicsFlash is nonvolatile memory which can be erased and rewritten. Readingfrom NOR Flash is just like reading from ROM or RAM. However, unlikeRAM, data cannot be altered on Flash just by writing to the locationconcerned. Flash must be erased before a write operation is possible, andwe can only do this erasing in relatively large units (called blocks). Toerase, the phone software must issue a command and then wait for thedevice to signal that the operation is complete. The erase sets each bitwithin a block to one.
Write operations, which are issued in the sameway as erases, can then change bits from one to zero – but not from zeroto one. The only way to change even a single zero bit back to a one is toerase the entire block again.Imagine that we need to modify just one byte of data in a block,changing at least one bit from zero to one. (Assume also that we cannotperform the modification by writing to an alternative location in theblock that has not yet been written to.) Then, to do this, we have tomove all the other valid data in the block to another freshly erasedlocation, together with the updated byte. The new location now replacesthe original block – which can then be erased and becomes available forreuse later.Another characteristic of Flash that we had to consider in our designis that it eventually wears out – there is a limit to the number of times ablock can be erased and rewritten.9.4.2.2 The logThe LFFS is specifically designed to operate with NOR Flash and to protectitself against power loss.
To do this, it keeps a log of all its operations(hence the ‘‘log’’ part of the name). It records each modification to thedata in the file system by adding an entry at the end of the log describingthe operation. So, if a new file is created, this information is added as alog. If the file is subsequently deleted, a log entry indicating that the fileis no longer available is added to the log.Each log entry is of fixed size (32 bytes) and includes a flag thatindicates the completion status of the operation. Before each operationis started, the LFFS creates its log entry which it adds to the log witha completion status of ‘‘not complete’’.
It then performs the operation,and only when this is fully complete does it modify the status in thelog entry to ‘‘complete’’. If an operation is incomplete when power isremoved then, when power is restored, the LFFS undoes the operationand any space it had consumed is reclaimed. This system ensures thatpower loss does not corrupt the file system – although data that is onlypartially written is lost.The LFFS uses the key characteristic of NOR Flash to implementthis scheme. We’ve seen that generally we can’t change Flash contentsFILE SYSTEMS369without a prior erase cycle.
However, we implement an ‘‘incomplete’’flag status using bits in the one state, and so we can rewrite this flag tozero (the ‘‘complete’’ state) without the need for an erase.A set of operations are often related to each other, in that the wholeset must either be completed, or the set of operations should fail.
In otherwords, all the changes must be committed atomically. As an example ofthis, consider a large file write involving several data blocks. To handlethis requirement, the LFFS uses a transaction mechanism. It marks alllog entries that are part of the same transaction with the transactionID number. It also marks the first entry with a transaction start flag,and the last entry with a transaction end flag. This ensures that partialtransactions are never regarded as valid. Either the transaction succeedsand all the associated operations are valid, or the transaction fails andall the operations are invalid.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
