Hello Mats,
Thank you for your response.
I very well understand the complexity involved in making a driver work cross
platform. I am aware that Windows provide a good OHCI driver as i have
tested it across machines by transmitting/receiving 1394 packets.
I have an multi utility application (like GPS processor, Speed calculator,
Warning system, 3D games, VOD-DVD, cell phones for in-bus info-entertainment
system ) written that runs on linux and Windows XP. I have used as much as
open source i can so that it is platform independent (like cygwin/X on
winxp, mesa GL etc). Also taken care so that the application has a small
footprint so that i can run on some low end microcontrollers
If i have my own 1394 compatible ohci, bus drivers, i need not re-write my
communication layer everytime i switch os. Also the inspiration is from
AL1394 project from Linux. This way i can concentrate my energies on
writting more applications and the lower end is taken care already.
This is an enhancement to the application making it 1394 aware.
Any resources to get me going would definetely mean a lot.
Regards,
Sivakumar Jayapal
-----Original Message-----
From: Mats PETERSSON [mailto:xxxxx@3dlabs.com]
Sent: Monday, April 25, 2005 4:21 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] How to write 1394 OHCI Driver
I’m sure there are good reasons to “write your own”, but Windows does
actually come with a pretty good OHCI driver…
Or are you talking of a “slave” driver, as the driver that talks to a Video
camera or some such device, rather than the 1394 card/chipset itself?
As for drivers working cross-OS, you’ll most likely find there are a few
things to consider here:
1: Differnet flavours of OS’s have different interfaces for the drivers,
which means that the way you tell the OS that “I’ve recieved a packet”, or
an application says “I’d like to receive/transmit packets of type X”, can
be VERY different.
2: The OS calls themselves are different. So to allocate some kernel memory
in Linux is done with a different call than a Windows driver, which both
are different from QNX’s.
3: Error/fault handling is different. The way you say that things went OK
in one OS may well be the same way that you say it went wrong (returning a
zero-value is a success in some places, but a failure in another). This
doesn’t just vary between different OS’s, but also WITHIN the same OS.
4: The interface to connect to hardware, and how you map hardware into the
OS/Kernel space is definitely different, and the way “Plug’n’play” affects
this is also quite different.
You can probably spend some time devicing a translation layer that
translates any inconsistencies from one architecture to another. It’s not
rocket science, and it should be possible to do. You’ll get another layer
or two between the raw OS-interface and the actual code that touches the
hardware. At the same time, it will probably make a bit of a difference how
you make this layer work. It’s quite important that you understand from the
beginning how the three (or however many you want to support) OS’s work
internally, how to interface all of them, etc. It’s quite easy to get
things wrong too, because you start off thinking that you shall base the
driver on a Windows principle, and then turn to the Linux driver and just
make a translation layer, then to realize that some aspect of the driver
isn’t going to work very efficiently, because some aspect of a Linux driver
is QUITE different than a Windows driver, and the way that to solve it
efficent in Windows prevents you from doing an efficient solution in Linux,
or the other way around. A lot of preparation and testing things out on all
three platforms at once will help here.
You may find that writing the translation layer(s) is taking more effort
than the actual driver source code took in the first place. Drivers are
highly connected with the OS that they run on… The different OS’s have
quite different internal architectures, and that can easily make the
interface mechanisms so different that you have to add a lot of internal
work to make it look similar.
Disclaimer: I’ve never written any really complex Linux drivers, so I don’t
know exactly how they work, and I’ve not EVER written a driver, or any
other software, for QNX.
–
Mats
xxxxx@lists.osr.com wrote on 04/25/2005 11:24:54 AM:
Hello,
I want to write a 1394 compatible OHCI driver for windows. Is it possible
to
write such a driver that can run on windows, QNX and Linux?
Where should i look for resources? Any sample source available?
Currently going thru the OHCI1.1 specification.
Kindly ignore the disclaimer.
Regards,
Sivakumar Jayapal
DISCLAIMER
This message and any attachment(s) contained here are information
that is confidential, proprietary to HCL Technologies
and its customers. Contents may be privileged or otherwise protected
by law. The information is solely intended for the
individual or the entity it is addressed to. If you are not the
intended recipient of this message, you are not authorized to
read, forward, print, retain, copy or disseminate this message or
any part of it. If you have received this e-mail in error,
please notify the sender immediately by return e-mail and delete it
from your computer
Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
ForwardSourceID:NT0001156E
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@ctd.hcltech.com
To unsubscribe send a blank email to xxxxx@lists.osr.com