I am trying to see how I could instantiate i2c-mux-gpio driver at run time from user-space.
Basically, the intent is to use a default version of the distribution but at run time determine based on certain parameters to instantiate the i2c-mux-gpio so that it can add more buses.
Example, something like
modprobe i2c-mux-gpio <"gpio0=1,gpio2=0">
The existing i2c-mux-gpio seems to take the required information via standard structure which happens to be populated via a device-tree/acpi etc.
Exploring if someone has already attempted to pass this information at run time.
Thanks
Sriaknth
If you're using the Device Tree on your platform, you should have a look at the recent Device Tree Overlay mechanism which was merged. It also to load additional fragments of Device Tree at runtime.
Related
I am new to windows filter drivers. From the sample code of (MSDN) what I have seen is that, File system filter driver, has Filter Manager associated with it, and process filter driver doesn't have Filter Manager associated with it. So why is that difference?
So need some suggestions and help.
It seems that you might want to read Windows Internals by Alex Ionescu, this will clear things up for you, starting from the bottom and will help you understand the whole thing.
Basically, in the past, filesystem filter drivers were built in a way that it would sit in a the right position in the exact filesystem DEVICE STACK, for example, NTFS. That way it would get the chance to filter IRPs.
Nowadays, the thing you mentioned, the filter manager (FLTMGR) has its own (legacy) driver at the top and on the bottom of the device stack, and it lets you register a callback function that everytime an IRP gets caughted, you'll get a chance to handle it.
Process (creation/deletion) filtering is a bit different, it is not handled using IRPs, basically in the call flow of NtCreateUserProcess on the kernel side there is a function responsible for calling whatever function registered for this kind of callback.
I hope that it clears things for you.
I am quite new to Linux and I was going through some online tutorial
and got over two ways for altering the kernel parameter:
create /lib/modprobe.d/XYZ.conf file and put for example something like options cdrom lockdoor=0
navigate to /etc/sysctl.d, create some file like mnq.conf and put something like aaa.bbb.ccc=0
What is the difference between these two ways?
To understand the difference, let's see when these parameters are applied to the boot process:
Kernel (vmlinuz) is loaded with default sysctl parameters (nowhere to read actual parameters yet). No modules (drivers) are present at the moment (these are separate entities!).
Kernel reads initial ram disk with modules
Kernel loads modules for disk drivers and other modules needed for booting. These drivers might need some tuning (i.e. certain SCSI devices might cause initialization timeouts without proper setting). These settings also need to be applied before starting driver initialization, hence modprobe and module params in general implementation.
...
System services are starting including sysctl service which applies both kernel and some module parameters dynamically (at runtime). Those parameters doesn't affect workability of the kernel, rather than simple stability/performance tuning.
I am trying to build a simple simulation using omnet++. I'd like to avoid using things like ned. Instead I want to allocate the modules set up the simulation topology entirely under program control. (i.e. I'll configure my simulation and set up connections etc. in main() instead of using ned)
How do I go about doing this ? (any examples you can point me to?)
thanks
Create a top level network in NED and drop a single simple module called builder or something like that. Then create/connect the necessary modules in that module's initialize method (or schedule a message at t=0s and do the network buildup there).
There is an example in OMNeT++ that does exactly like this, in samples/routing. Choose the NetBuilder configuration. That example is reading the network topology from an external file, but you can change it to create any topology you would like to have.
The actual code for the network generation is in samples/routing/builder/netbuilder.cc in NetBuilder::buildNetwork
Okay first a little context. I have started working on a project in my uni, one of the goals of which are to develop a module that will log when a process tries to:
-create, delete or modify a file (filesystem activity basically)
-create, detete or modify a registry id/value
We will actually be specifying a process for this module to monitor, and whenever this process tries to perform any of the activities listed above it will get logged.
Right now, i am looking into the basics of Driver development, and Filter Drivers as suggested by my DS. Here is my question,
What would be the best method to achieve this, would it be by writing a filter driver of some sort? if yes than exactly what filter driver, a filesystem filter driver or a minifilter driver or something else? Or don't know maybe some other technique?
I just need a little direction, so that i can do targeted research and implementation, as i don't have much time for this project!
File system minifilter drivers is the way to do this.
But the tricky part would be how do specify process to monitor. If you are thinking of PID then its quite straight forward, but if you are thinking of using process/executable name like notepad.exe then that becomes little complicated.
Just to give you hint, you can get PID for the operation in mini filter but not process name. So you will have to maintain a map of PID to process name in your minifilter driver. You way want to use PsSetCreateProcessNotifyRoutineEx and PsSetLoadImageNotifyRoutine.
I have a NDIS driver, which gets listed both in connection properties's installed items list and in device manager; the question is, how do I write an extension which will be used for managing driver's properties, and how to install it?
Of course, a plain GUI program may communicate with the driver, set properties, get version numbers and other statistical info etc, that's what DeviceIoControl exists for; but, does this means that no dedicated interface exists to inform the driver about configuration changes?
It would be pleasant if someone can forward this question to eggheadcafe/osr's ntdev lists.
If you want your network driver to have some UI in the LAN Properties dialog, then you need to do these things:
Create a NotifyObject (if you don't have one already)
A NotifyObject is essentially a COM object associated with your driver. To make one,
Make a DLL that can create your new COM class. (If you use ATL's class factory, it's only a couple lines of code. I highly recommend using ATL for implementing COM objects. This is out-of-scope of the LAN Properties GUI, but you should look up DllGetClassObject, a C++ class that inherits from CComObjectRoot and CComCoClass, a call to OBJECT_ENTRY_AUTO, and a BEGIN_COM_MAP if you're new to COM.)
Associate your COM object with the driver by putting ClsId={guid} and ComponentDll=filename into your INF.
Implement INetCfgComponentPropertyUi on your COM object
The key method is MergePropPages. In this method, you allocate propertysheet pages and merge them into the adapter properties. This operation looks something like this pseudocode:
HPROPSHEETPAGE *psharray = CoTaskMemAlloc(NUMBER_OF_PAGES * sizeof(HPROPSHEETPAGE);
for (i = 0; i < NUMBER_OF_PAGES; i++)
psharray[i] = CreatePropertySheetPage(&psp);
The API is meant to be transactional. Make sure to apply any changes in the ApplyProperties method, and (if applicable) undo them in CancelProperties.
You don't need to do anything in QueryPropertyUi or SetContext, although you might want to save the context if you need to get the registry key location.
Test your changes
If all goes well, then your new Notify Object will be loaded up every time there are any network configuration changes. If the GUI is being displayed, then Windows will query your class for the INetCfgComponentPropertyUi interface and call MergePropPages.
I find it helpful to put hardcoded breakpoints in my DLL at key locations, and then attach a kernel debugger so that I can always find the DLL, no matter which process is loading it. (On Windows 7, you'll be loaded in drvinst.exe, which can be hard to find with a usermode debugger.)