Writing an Intelligent Serial Card Driver

Every wonder what it's like to write a driver under Linux? Here's a summary of one hacker's experiences.
Capabilities
  • auto-detects card and uses assigned IRQ for given address

  • presents DTR as function of open/close status

  • can send/receive data on all eight ports

  • works for login session from terminal problems

  • reception of character before transmitting first character is seen as a “hangup” by something; once first character is sent, reception works fine shortcomings

  • speed is fixed at 9600 baud

  • mode is fixed at 8 bits, No parity, 1 stop bit

  • modem status is ignored

  • wait-on-open doesn't wait

  • break is ignored

  • written for release 0.99p12 testing

  • haven't tested simultaneous send/receive

  • haven't tested simultaneous multi-port operation

And a few days later I added:

It appears the problem I reported for the Cyclodes driver is actually deeper within the kernel and appears with the other asynchronous drivers, i.e., it was there to begin with. Therefore I will ignore this problem for the moment, since the other ports work for all applications I know, and focus on getting the rest of the features right. First will be speed and line mode stuff, then the modem control.

and then:

I've dropped in the speed setting code and tested it at speeds up to 19200. Once I rig some kind of loop-back cable, I'll check higher speeds.

It now recognizes parity errors and break, the wait-on-open feature works, and multiple simultaneous sends and receives have been tested. The upgrade to kernel 1.1.8 is done and I'm working with some other folks on testing it more rigorously.

Checking back in my log one can see how I worked in spurts. I spent a bit over a week overall on this, mostly in day-long chunks. This was after a lot of hour-long periods reading the documentation.

So what did I gain and would I do it again?

I got a chance to pay my debt to the community. I got to play inside the kernel. I'm more confident that I can write drivers for this system and get them to work. I also got a mux board.

I'm not sure I would do it again. Not that it was that demanding, but it did take time. I don't think the gains would be as great the second time around. Still, if an interesting-enough device was offered to me, I'd be tempted.

Randolph Bentson can be reached at: (bentson@grieg.seaslug.org)

______________________

Webcast
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers

Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.

Learn More

Sponsored by AMD

White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions