Suppose I have pointer to struct inode, references some special file.
How it can be found which driver is placed under this inode?
Generally, you cannot deduce driver from the inode object. But if driver is compiled as module, the way below may help.
You can check inode->i_fop->owner field. If it is non-NULL, it refers to the module (struct module), which implements it. Macro module_name(mod) returns name of that module.
Related
Referring to LDD-3 pg-50. It is written that
struct module *owner
The first file_operations field is not an operation at all; it is a pointer to the module that “owns” the structure. This field is used to prevent the module from being unloaded while its operations are in use. Almost all the time, it is simply initialized to THIS_MODULE.
If we refer LDD-2 the explanation is
"This field isn’t a method like everything else in the file_operations structure. Instead, it is a pointer to the module that “owns” this structure; it is used by the kernel to maintain the module’s usage count."
Now my question is how this field is actually preventing the module from being unloaded ?
Thanks,
When a file which uses these operations is opened, before .open() file's operation is called, a function try_module_get() is called for the .owner module. This increments the module's usage counter, so the module cannot be unloaded with rmmod command.
When last reference to the file is dropped, and its .release() operation is completed, a function module_put is called for .owner module. This decrements module's usage counter, so the module can be unloaded again (unless its reference counter has been incremented for other reason).
I am working on a driver that creates a sysfs attribute file. It is intended that an application be notified of changes to this attribute by using the poll() method. I intend to use the sysfs_notify() function for this. This is easy to do as long as you have the kobject for the attribute (sysfs_notify() requires that as the first parameter). Getting the kobject is easy enough if using sysfs_create_file() and related functions.
I read this post on correctly creating a sysfs file that solves a possible race condition between userspace notification that the device is present, and the creation of the sysfs files. This solution is also much cleaner.
However, I cannot figure out how to get the kobject for each of the attributes (or parent) that I can use in sysfs_notify(). At one point structures such as struct device_driver had a member of struct kobject kobj;. That was replaced (10ish years ago) with struct driver_private *p;. This private structure now contains the actual kobject and is not available for use.
Is there a new form of sysfs_notify() that I can use, or is there another way of getting the correct kobject? I may have to go back to "manually" creating the sysfs attribute otherwise.
It is mentioned in Scott Meyer's book that part of the overhead caused by using shared pointers is that they need virutal function to destroy the pointed object correctly. My question is why? Is this not supposed to be the responsibility of the class of that pointed object to have a virtual destructor?
Is this not supposed to be the reponsibility of the class of that pointed object to have a virtual destructor?
That would be one possible way to design a shared pointer, but std::shared_ptr allows you to do the following, even if Base does not have a virtual destructor:
std::shared_ptr<Base> p { new Derived{} };
It does this by capturing the correct deleter for the argument when the std::shared_ptr is constructed, then calls that when the reference count hits zero rather than just using delete (of course, you can pass your own custom deleter to use instead). This is commonly referred to as type erasure, and this technique is generally implemented using virtual function calls.
I hooked the CopyItems method of IFileOperation to monitor/intercept file copy in windows.
My problem is how can i retrieve the full file name from IShellItem(last param of CopyItems)
function New_CopyItems(p: Pointer; punkItems: IUnknown;psiDestinationFolder: IShellItem): HResult; stdcall;
The psiDestinationFolder have a method called GetDisplayName that return only the folder name of current file was begin copied!! But i want to get full file name and don't know what i should to do !? There is any other method to help me getting full name ?? Or i have to using another API ....?
Excuse me if my English is bad!
The CopyItems method copies potentially multiple items. So right off the bat you are mistaken looking for a single file name. This is a very complex API and you do need to read the documentation carefully and understand clearly how the function works.
The psiDestinationFolder parameter is an IShellItem that identifies the destination. Use the GetDisplayName method to get the file path.
The other parameter, punkItems is more complex. It is documented like this:
Pointer to the IUnknown of the IShellItemArray, IDataObject, or IEnumShellItems object which represents the group of items to be copied. You can also point to an IPersistIDList object to represent a single item, effectively accomplishing the same function as IFileOperation::CopyItem.
This is telling you that there could be an IShellItemArray, IDataObject, IEnumShellItems or a IPersistIDList object behind the IUnknown interface that you receive. And that there could be multiple items in that single object, each one to be copied to the destination folder. You will need to query punkItems for each possible interface in turn until you find out which of these possibilities you have to deal with. And then handle each one with special code. In order to test this you'll need to write code that calls CopyItems with each of the possible interfaces. You'll find out how to do all of this from the documentation of each of the four interfaces. If you don't already know shell programming and COM well, expect to do so by the time you complete this work.
Finally, I doubt that this is a very good way to detect file copying. Files are copied using many different APIs. And IFileOperation.CopyItems is but one of them. If you only hook IFileOperation.CopyItems then you'll miss a lot of file copy operations.
Is there any way for a consumer to enumerate all interfaces implemented by a given COM object?
You can try IDispatch/IDispatchEx if you simply want to know what methods are callable from your consumer.
In COM, the QueryInterface method on IUnknown is not required to expose what interfaces it may return. You ask for one based on its IID and you either get it or not. The implementation of QI in a particular COM object varies considerably although it's supposed to follow the pattern described by Microsoft here - http://msdn.microsoft.com/en-us/library/ms682521%28VS.85%29.aspx.
Dependency Walker won't show the interfaces as the only exports are DllGetClassObject, DllRegisterServer, etc (for DLL-hosted COM).
You may, as weismat says, inspect the TLB files. Many COM objects contain embedded typelibs in the resource section of the executable. With a tool such as resource hacker you can extract the TLBs and use LoadTypeLib COM functions to get a pointer to ITypeLib interface (you could use LoadTypeLib/LoadTypeLibEx directly with a COM or EXE DLL, of course).
WIth this interface you can iterate over the types contained within.
Dependency Walker might do the job for you...
http://theircorp.byethost11.com/index.php?vw=TypeLib is a free tool to examine the TBL files.