Author Topic: SOME steps to write device drivers...  (Read 5508 times)

Roderick Klein

  • Hero Member
  • *****
  • Posts: 655
  • Karma: +14/-0
    • View Profile
SOME steps to write device drivers...
« on: June 10, 2015, 11:04:25 pm »
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.html

You 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

« Last Edit: June 10, 2015, 11:34:23 pm by Roderick Klein »

Roderick Klein

  • Hero Member
  • *****
  • Posts: 655
  • Karma: +14/-0
    • View Profile
Re: SOME steps to write device drivers...
« Reply #1 on: June 11, 2015, 12:07:18 am »
Replying to my own post... :-)

If you wanne write a driver that talks to hardware you need to read the specifications. From what I have seen reading specs of chips in in my opinion in trade in itself.

If you can not find specs from the manufactor its down to seeing what the Linux folks did ot another platform.  This last thing is maybe also not the easiest in call cases as you need to read kernel sources of a different platform.

I can not comment on the driver libraries I linked to from David, as I said I need to make time to put the Warpsrtock Europe 2015 presenations online.. Its down to reading the redbooks from IBM how to use the kernel debugger. What I have always seen is writing a driver is not maybe the most difficult thing. But I know developers that rather stick with applications then drivers and visa versa.

The real crunch begins when you have to turn a driver in a quality code. The last 20% of labour which takes most of the time is hunting down the bugs and fixing them in a proper way.

I think thats all I could write with my more then 10 years of assisting developers with debugging device drivers for OS/2.
« Last Edit: June 11, 2015, 12:10:07 am by Roderick Klein »

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: SOME steps to write device drivers...
« Reply #2 on: June 11, 2015, 05:55:31 am »
Quote
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.

IMO this should be mandatory for all programs, drivers, DLLs, and anything else that you can think of. Without it, you really can't tell what the bldlevel information really is. Apparently, adding the information is trivial, in most cases.