I keep claiming writing device drivers takes a certain level of skillset. If you wanne write device drivers.
You could look at the eCS CD 2 as there is a kit on it how to write device drivers (presentation from Daniela).
It also has a ZIP file with some examples. It has been on eCS CD #2 since version 12 of eCS I think.
The other thing are these libraries David. He has had them around for some time and they have been on his website.
I hope next week when I get back from vacation I can get the presentations online on the website and the video's on youtube. Then you guys can see how these libraries should make writing device drivers easier.
http://88watts.net/software.htmlYou do however need a DDK. As the DDK contains some libraries and a lot of header files.
I need to get David his presentations online so people can see what he said. But from what I remember of David his presentayion it should make live _easier_. As these libraries provide a basic skeleton to write drivers.
Using device driver samples from the DDK should be done with caution. I do not know if the last version of the DDK released has for example this issue fixed. SiS and VIA released OS/2 drivers for some of its NIC chipsets.
From what I remember they would crash because they had some ISA code in it claim PCI IRQ"s via the resource manager exclusively. Sadly SiS or VIA never fixed this issue.
Writing device drivers is not maybe that difficult. What can become difficult is when a device driver causes a kernel crash. Tracing that can be a pretty time consuming job. I did plenty of does things at Mensys and some jobs took more then 40 to 60 hours to trace back (even with in my opinion very skilled develoeprs). It especialy becomes difficult when a driver for example corrupts memory and you need trace back what corrupted the memory. Finding it and fixing it can be very time consuming job.
A lot of these problems can be prevented by commenting code properly and checking in changes into SVN frequently. So you can trace back when you introduced the defect. It takes longer, but pays itself back in gold when you run into trouble. Frequent checkings I have even seen paid developers not do this very often. Finding the broken code then only takes longer as you made more changes between the working and none working code set.
I have had it with severeal people and 1 company I hired at Mensys where dispite putting in the contract frequent checkins where required. They did not check in the code for months. It took 3 project managers 2 developers after 9 months they gave up on a trap in a driver. One of the well known developers in the community traced it down and fixed it about 45 minutes....
The thing where the skillset comes in is to understand what you are doing. I have at Mensys for years try to help a lot of people to write device drivers. But seing how many people got stuck. Its certainly from what I have seen is easier to write applications then drivers. As when a driver takes down the system you are down to memory dumps or kernel debugging in some cases...
Some tools that can help and tools you have been online here for many years:
http://www.warpcave.com/(Page of Steve Levine).
And even when you stick to these rules it can still be extremely time confusing to trace bug. In my opinion learning how to use the OS/2 kernel debugger is not learned in a few days...
And if you do release drivers a developer. But bldevels in the driver (that can be read with bldlevel.exe command). Do not be depended on date and time stamp of the driver. So that every public release can linked to the code in SVN.
Also release your driver with a so called SYM file. That makes tracing bugs for other developers eaiser.
I do not know how you create such a file but its easier for other developers if you have a SYM file to trace code in memory dump or kernel debugger. As you will see function names etc... I hope I explained this last bit correctly...
Roderick Klein
President OS/2 VOICE
Show Posts