1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/os/kernelhwsrv/userlibandfileserver/fileserver/sfsrv/cl_notification.h Fri Jun 15 03:10:57 2012 +0200
1.3 @@ -0,0 +1,161 @@
1.4 +// Copyright (c) 1995-2009 Nokia Corporation and/or its subsidiary(-ies).
1.5 +// All rights reserved.
1.6 +// This component and the accompanying materials are made available
1.7 +// under the terms of the License "Eclipse Public License v1.0"
1.8 +// which accompanies this distribution, and is available
1.9 +// at the URL "http://www.eclipse.org/legal/epl-v10.html".
1.10 +//
1.11 +// Initial Contributors:
1.12 +// Nokia Corporation - initial contribution.
1.13 +//
1.14 +// Contributors:
1.15 +//
1.16 +// Description:
1.17 +// fileserver/sfsrv/clnotification.h
1.18 +//
1.19 +
1.20 +/**
1.21 + * @file
1.22 + * @internalTechnology
1.23 + * @released
1.24 + */
1.25 +
1.26 +#ifndef __CLNOTIFICATION_H__
1.27 +#define __CLNOTIFICATION_H__
1.28 +
1.29 +#include "f32notification.h"
1.30 +
1.31 +/*
1.32 + * This comment is:
1.33 + * @internalTechnology
1.34 + *
1.35 + * In general, the getter functions for TFsNotification extract data from a given buffer in the order:
1.36 + * <Notification Size> <Path Length> <Type> <Path> [any sub-class members]
1.37 + * Notification of type EOverflow doesn't have a path associated with it
1.38 + * If a new name exists (ERename, EVolumeName and EDriveName) then the order is:
1.39 + * <Notification Size> <Path Length> <New Name Length> <Type> <Path> <New Name>
1.40 + * For EAttribute the order is:
1.41 + * <Notification Size> <Path Length> <Type> <Path> <Attribute>
1.42 + * For EFileChange the order is:
1.43 + * <Notification Size> <Path Length> <Type> <Path> <File Size>
1.44 + */
1.45 +
1.46 +/**
1.47 + * A Mask of all the valid filters that a client can set
1.48 + * @internalTechnology
1.49 + */
1.50 +const TInt KNotificationValidFiltersMask = (TUint)(
1.51 + TFsNotification::EAttribute |
1.52 + TFsNotification::ECreate |
1.53 + TFsNotification::EDelete |
1.54 + TFsNotification::EDriveName |
1.55 + TFsNotification::EFileChange |
1.56 + TFsNotification::EMediaChange |
1.57 + TFsNotification::ERename |
1.58 + TFsNotification::EVolumeName
1.59 + );
1.60 +
1.61 +/*
1.62 + * Different notification types have different data associated with them.
1.63 + *
1.64 + * All types have the following data and are aligned in the buffer like so:
1.65 + * Word1 : Size (TUint16 - upper 2 bytes) , NameLength (TUint16 - lower 2 bytes),
1.66 + * Word2 : Type (TUint - 4 bytes)
1.67 + * [not yet supported - Word3 : UID (TUint32 - 4 Bytes) ]
1.68 + *
1.69 + @internalTechnology
1.70 + @released
1.71 + */
1.72 +const TInt KNotificationHeaderSize = (sizeof(TUint16)*2)+(sizeof(TUint));
1.73 +//
1.74 +//When UID is added:
1.75 +//const TInt KNotificationHeaderSize = (sizeof(TUint16)*2)+(sizeof(TUint))+sizeof(TUint32);
1.76 +
1.77 +/*
1.78 + * This is the minimum allowed size of the buffer set by the client that is
1.79 + * equal to the size of a notification of maximum length and an overflow
1.80 + *
1.81 +@internalTechnology
1.82 +@released
1.83 +*/
1.84 +const TInt KMinNotificationBufferSize = 2*KNotificationHeaderSize + 2*KMaxFileName;
1.85 +
1.86 +
1.87 +
1.88 +/**
1.89 + * Fill any dead space at the end of the buffer with this
1.90 + * If there is any dead space it should always be at least 1 word in size
1.91 + * @internalTechnology
1.92 + */
1.93 +const TUint KNotificationBufferFiller = 0xFFFFFFFF;
1.94 +
1.95 +class TFsNotification; //forward ref
1.96 +
1.97 +/* This class is used as the buffer in the file server notifier framework.
1.98 + *
1.99 + * The buffer itself is simply a descriptor.
1.100 + *
1.101 + * This class is internal because we may wish to change the
1.102 + * buffer mechanism in the future without BC breaks etc.
1.103 + *
1.104 + * @internalTechnology
1.105 + */
1.106 +class CFsNotificationList : public CBase
1.107 + {
1.108 +public:
1.109 + static CFsNotificationList* NewL(TInt aBufferSize);
1.110 + virtual ~CFsNotificationList();
1.111 +
1.112 +private:
1.113 + CFsNotificationList();
1.114 + const TFsNotification * NextNotification();
1.115 + TInt BufferSize() const;
1.116 +
1.117 + HBufC8* iBuf; //Heap based to allow buffer size spec at runtime
1.118 + TInt iHead; //offset to the head of the readable data.
1.119 + TInt iTail; //offset to end of the readable data.
1.120 +
1.121 + TPckg<TInt> iTailPckg; //stores iTail, used in Asyc IPC
1.122 + TPtr8 iBufferPtr; //stores iBuf->Ptr, used in Asyc IPC
1.123 + friend class RFsNotify;
1.124 + friend class CFsNotify;
1.125 + };
1.126 +
1.127 +/**
1.128 + * @internalTechnology
1.129 + */
1.130 +class RFsNotify : public RSubSessionBase
1.131 + {
1.132 + public:
1.133 + TInt Open(RFs& aFs,CFsNotificationList* aBuffer, TRequestStatus& aBufferStatus);
1.134 + void Close();
1.135 +
1.136 + //[Re]Issues notification request
1.137 + void RequestNotifications(TRequestStatus& aStatus, TPckg<TInt>& aTailPckg);
1.138 + TInt CancelNotifications();
1.139 + TInt AddNotification(TUint aNotificationType, const TDesC& aPath, const TDesC& aFilename);
1.140 + TInt RemoveNotifications();
1.141 + };
1.142 +
1.143 +/**
1.144 + * @internalTechnology
1.145 + *
1.146 + * This class is the iBody of CFsNotify. It is being used to shield the client from the internals which are being stored here.
1.147 + *
1.148 + * @see CFsNotify
1.149 + */
1.150 +class CFsNotifyBody : public CBase
1.151 + {
1.152 +public:
1.153 + virtual ~CFsNotifyBody();
1.154 +private:
1.155 + CFsNotifyBody();
1.156 + TRequestStatus iBufferStatus; //for server->buffer updates
1.157 + TRequestStatus* iClientStatus; //Client's TRS:for receiving notification
1.158 + CFsNotificationList* iBuffer; //Buffer into which the server puts the notifications
1.159 + RFsNotify iFsNotify;
1.160 +
1.161 + friend class CFsNotify;
1.162 + };
1.163 +#endif //__CLNOTIFICATION_H__
1.164 +