Wiley.Symbian.OS.Internals.Real.time.Kernel.Programming.Dec.2005.eBook-DDU (779891), страница 76
Текст из файла (страница 76)
It maintains aTDrive instance for each drive, whether or not the drive is currentlymounted. As I mentioned in Section 9.1.2, mounting a drive meansassociating a file system with it. TDrive contains the member iFSys,which is a pointer to a file system factory class, CFileSystem. WheniFSys is NULL, the drive is not mounted. (Some drives are available fordrive substitution but substitute drives have no associated file system.)360THE FILE SERVERThe TDrive data member iAtt holds a bit-mask of the driveattributes. These attributes are fixed while the drive is mounted witha particular file system. The set of possible drive attributes is as follows:AttributeDescriptionKDriveAttLocalDrive is local.
Uses the local mediasub-system (not ROM or remote).KDriveAttRomA ROM drive.KDriveAttSubstedDrive is a substitute to a path onanother drive.KDriveAttInternalDrive is internal (as opposed toremovable).KDriveAttRemovableDrive is removable.KDriveAttRemoteDrive is remote.KDriveAttTransactionDrive employs a file system which istransactional (this is used by STORE).In fact, in the context of drives, the term ‘‘mount’’ is a little over-used,since we also talk about a volume being ‘‘mounted’’ on a drive. The classCMountCB is an abstraction of a volume (or partition).
For removablemedia devices, the file server creates a different CMountCB object foreach volume introduced into the system. If the user removes a volumefrom the phone with a sub-session object still open on it (for example,an open file), then the file server cannot destroy the correspondingCMountCB object.TDrive maintains an object container, iMount, holding all the openmounts on its drive. TDrive also keeps a separate CMountCB pointer,iCurrentMount, corresponding to the volume that is currently presenton the phone. For a CMountCB object to be destroyed, there mustbe no sub-session objects open on it and it must not be the currentmount.The Boolean member TDrive::iChanged indicates a possiblechange of volume, and is important for removable media drives. Atstartup, the file server passes down to the local media sub-system theaddress of iChanged for each local drive that is enabled on the phone.The local media sub-system will then update this variable each time thereis a card insertion or removal event for the drive concerned.THE FILE SERVER361Each volume contains a unique identifier – for example, FAT partitionscontain a unique ID field in their boot sector.
The file server reads this IDwhen it mounts the volume on the drive and stores it in the correspondingmount object, CMountCB::iUniqueID. If the user changes the mediain the drive, then when the file server next accesses that drive, it will findiChanged to be true. The file server then reads the unique ID directlyfrom the new volume to determine if the volume has changed. The servercompares the unique ID that it has just read with the ID of each existingmount object stored in the mount queue, to see if it already knows aboutthis volume.
If it does, then the corresponding mount object becomes thecurrent mount again. If it does not, then it creates a new mount object.9.3.3.2 CMountCB classThe volume abstraction, CMountCB, has members holding the size ofthe volume in bytes, iSize, and the volume name, iVolumeName. Italso has a member iMountQ, which is a list of all the files open on thevolume.Its member, iLockMount, is a lock counter, which tracks whetherfiles or directories are opened, and whether a format or raw disk access isactive on the volume. The server checks iLockMount prior to processingformat and raw disk requests on the drive, as these can’t be allowed whilefiles or directories are still open.
Similarly it checks this member beforeopening files or directories on the drive to ensure that a format or rawdisk access is not in progress.9.3.3.3 Request dispatchNow let us look in a little more detail at what happens when a clientrequest is dispatched to a drive thread.As I described in Section 9.3.2.4, before it dispatches the requestto the drive thread, the server’s main thread calls TOperation::Initialise() to preprocess and validate the data suppliedby the client.
This may involve assembling a full drive, path and filenamefrom a combination of the data supplied and the session’s current path.If the request involves a sub-session object (for example, CFileShare)then this process of validation will lead to the identification of the targetsub-session object. Rather than discarding this information and recalculating it again in the drive thread when request processing commences,the main thread saves a pointer to the sub-session object in the scratchvariable CFsRequest::iScatchValue so that the drive thread canre-use it.It is also at this initial stage that the main thread translates a requestspecifying a substituted drive.
The data member TDrive::iSubstedDrive provides a pointer to the true drive object (or the next one in thechain), and TDrive::iSubst holds the assigned path on this drive.362THE FILE SERVERThe drive thread commences its processing of the request by calling TOperation::DoRequestL(). It identifies the appropriate serverobject to be used to perform the request (often via the scratch variable).Requests translate into server objects as follows:Client requestServer objectRFsCMountCBRFileCFileCBRDirCDirCBRFormatCFormatCBRRawDiskCRawDiskCBRequest execution continues with the drive thread calling methods onthe server object. The first thing it normally does is to check that the targetdrive is mounted with a volume.These server object classes form the major part of the API to the filesystems.
This API is a polymorphic interface – each server object is anabstract class that is implemented in each separate file system DLL. Theserver manipulates these server objects using the base class’s API and thisallows it to work with different file systems in different DLLs. In this way,request processing is passed down to the appropriate file system.9.3.4NotifiersAs I mentioned in Section 9.2.1, the file server API allows clients toregister for notification of various events.
These include:• Standard change notification events:– Changes to any file or directory on all drives– Disk events such as a drive being mounted, unmounted, formatted,removed and so on• Extended change notification events. These are changes to a particularfile or directory on one or more drives• Disk space notification events: when free disk space on a drive crossesa specified threshold value.The client calls to register for notification are asynchronous: they returnto the client as soon as the message is sent to the file server.
The serverTHE FILE SERVER363doesn’t complete the message until the notification event occurs (or therequest is canceled). This completion signals the notification back to theclient.The server creates a notification object for each notification request.Figure 9.12 shows a diagram of the classes concerned. CNotifyInfois the base class for each notification. This contains an RMessagePtr2member, iMessage, which the server uses to complete the requestmessage when the notification event occurs.
It also contains the memberiSession, which is a pointer to the session on which the notificationwas requested. On session closure, the file server uses this to identify anynotifiers still pending for the session and cancel them.CNotifyInfo also stores a pointer to the client’s request status object,iStatus, which the client/server framework signals if the notifier is completed.
We need this to handle the client’s cancellation of a specific notification request. For example, the client can cancel a request for changeFsNotify11iDiskSpaceQuesiChangeQues27TChangeQue27TDiskSpaceQueCNotifyInfo1iType : TInfoTypeiStatus : TRequestStatus*iMessage : RMessagePtr2iSession : CSessionFs*1iHeaderiHeadernCDiskSpaceInfoiThreshold : TInt64nCStdChangeInfoiChangeType : TNotifyTypeCExtChangeInfoiName : TFileNameFigure 9.12 The F32 server-side notifier classes364THE FILE SERVERnotification using RFs::NotifyChangeCancel(TRequestStatus&aStat), where aStat supplies a reference to the request status objectof the notifier to cancel. The member iStatus is used to identify thespecific notifier concerned.We derive CStdChangeInfo from CNotifyInfo for standardchange notifiers.
This in turn is a base class for the extended changenotifier class, CExtChangeInfo. This class’s member iName holds thename of the specific file or directory associated with the notifier. We alsouse the CDiskSpaceInfo class, which represents a disk space notifier.The server uses the static class FsNotify to manage the notificationobjects.
FsNotify keeps two separate sets of queues, one set for changenotifiers and one set for disk space notifiers. Each set has 27 queueswithin it, one for each supported drive and one more to hold notifiersthat apply to all drives.Users of the F32 notification APIs should be aware of the potential forperformance degradation. Each time the server completes any request,it may also have to complete a pending notifier. The server checks theTOperation object of the request it is completing, to determine if therequest type is one which could potentially trigger either a disk spaceor a change notifier.
If it is, then the server iterates through two queueschecking for notifiers in need of completion. (Two queues because oneis for the current drive, and one is for notifiers that apply to all drives.)In the case of extended change notifiers, a certain amount of pathnamecomparison is required, and for disk space notifiers, the amount of freedisk space needs recalculating. If there are a large number of notifierspending, then this can have an impact on file server performance.9.4 File systemsThe file server receives all client requests, but it never accesses the mediadevices directly. Instead, it passes any requests that require access tothe directories and files on the device to a file system.
Each file systememploys a media format which is appropriate for the characteristics ofthe devices that use it. Most file systems are implemented as separate fileserver plug-in DLLs, the exception being the ROM file system, which isbuilt as part of the file server itself. File system DLLs are assigned the fileextension: FSY.Symbian OS supports the following file systems:• The ROM file system is used for code storage on execute-in-place(XIP) media such as NOR Flash. XIP refers to the capability to executecode directly out of the memory• The log Flash file system (LFFS) for user-data storage on NOR Flash• The FAT file system for user-data storage on NAND Flash, internalRAM drives and removable mediaFILE SYSTEMS365• The Read-Only file system (ROFS) for code storage on non-XIP mediasuch as NAND Flash.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
