Linux TPM driver porting

[Batuta]

...

[jdhurst]

Linux does not have a registry, so whereas Windows programs store dynamic and static settings and information in the registry, Linux drivers (at least the ones I have set) are compiled programs that keep settings in files. So if I were adjusting resolution in Linux, I would go to the XF86Config file and edit it. It's a very different concept than Windows.
... JD Hurst

[runixd]

Batuta, in Linux you would code a third party driver as loadable module, which could talk to hardware, basic rules are rather simple: you'r provided with diverse API (http://kernelnewbies.org/documents/kdoc ... elapi.html), you are provided with device specs and what it can do, so you can start right away. There are obvious restrictions, e.g. use of float variables and there are some linux kernel specifics, you should probably get indepth documentation on that. In your case, TPM is provided with clean source for kernel module and API for applications to use, those should be more than enough to start porting, providing you'r familiar with architecture you'r porting to.

[Batuta]

...

[jdhurst]

With the caveat that I have never done device drivers, I see that VMware provides a video driver for Linux but does not alter the kernel to make it run. I always just use the vanilla kernel for the Linux distribution I am running. With that in mind, I have seen sites where you can turn some programs into daemons such as www.dapper.org/software/daemonize. Perhaps there is a clue in there to getting your driver to run without changing the kernel. There were a number of sites I found while trying to google for UNIX daemon. ... JD Hurst

[runixd]

well lets see, firstly with linux you have a choice between loadable module and statically compiled driver, the latter is obviously your concern. But you don't have to go that route and assume you choose a loadable module. It will have to be linked with kernel in order to use API, but it doesn't mean that you have to fiddle with kernel in any way. It is recommended that you use kernel build system to build your module, but is not required, you can just as well work on it without ever running kernels make. You may load and unload your module at any time (of course unless you crash the whole thing:)).

When I compile this driver, I'll have to do it w/o any kernel part being involved into what will basically be a stand alone piece of code.

In here, as I understand you a worring about integrating driver code into kernel. This is not the case, a module is developed independently, but of course it does use kernel code in order to do anything.

So really we can conclude there is little theoretical difference for driver developer. There is a nice oreilly book on kernel device drivers, but it will probably be a little heavy since you only need to understand how it works and not develop, but there are a few good articles online, which you might spend time on. Also, have a look at this http://people.redhat.com/arjanv/olspaper.pdf .

[Batuta]

...

[runixd]

Providing you have similar headers and similar functions in OS/2, it shouldn't be too dificult. I don't know much about OS/2, but I assume you do, so If you just go through driver and see what it does (its only 600 lines anyway) and see if OS/2 provides you with the same, you shouldn't have many problems.