Linux Driver Porting Information

[0xCesar]

From what I know, though, most linux drivers are coded using assembly.

Well, you are wrong. Linux drivers are written in C.

[FlyingIsFun1217]

I don't see how that would be possible if they were assembly unless they ported the drivers each time.

Well, wouldn't they? Drivers aren't portable to my understanding.

I'll check out wikipedia, to make sure I'm not feeding everybody evil lies!

FlyingIsFun1217

[FlyingIsFun1217]

Hey! Cool! I'm wrong!

I never realized:

In order to develop Linux device drivers, it is necessary to have an understanding of the following:

C programming. Some in-depth knowledge of C programming is needed, like pointer usage, bit manipulating functions, etc.

Microprocessor programming. It is necessary to know how microcomputers work internally: memory addressing, interrupts, etc. All of these concepts should be familiar to an assembler programmer.

(http://www.freesoftwaremagazine.com/art ... vers_linux)

So I guess what I was getting messed up on is that they can be coded in C, but use assembly ideas.

Nevermind, disregard me!
FlyingIsFun1217

[GreatLord]

Windows and reactos provide all low level api u need.
and using asm in driver are against windows and reactos desgin.
it is total forbien. people please read how windows driver desgin before speak.

[FlyingIsFun1217]

Windows and reactos provide all low level api u need.
and using asm in driver are against windows and reactos desgin.
it is total forbien. people please read how windows driver desgin before speak.

Greatlord, I meant translating. I was misunderstood that linux drivers were mostly coded in assembly (which they are not). To translate that, you would need to know assembly.

FlyingIsFun1217

[Mna.]

So, I am wondering, Are there any guide of porting Linux driver to Reactos?
or at least from Linux to Windows?

[Haos]

I really doubt that, its more of crafting, artistic job, rather than something you coul tutorialize.

[Mna.]

The only thing somehow similar I found at the moment is:

A Comparison of the Linux and Windows Device Driver Architectures
http://osll.spb.ru/attachments/183/Linu ... arison.pdf

[Mna.]

Haos » 06 Jan 2011 11:13
I really doubt that, its more of crafting, artistic job, rather than something you could tutorialize.

I haven't yet dug it thoroughly, but does this type of job or driver porting really require intense research at every step?,
and couldn't this process made easy by outlining of important knowledge and eventually automated in some or other way?

***
Other paper I've found:
Comparing Windows XP and Linux. Windows Operating System Internals - by David A. Solomon and al.
http://fmgroup.polito.it/cabodi/dida/ps ... -linux.ppt

Interesting document about course of how USB appears in Linux: the similar way as people do for ROS, antisimmetric way, I would say:
"Reverse engineering Windows USB device drivers for the purpose of
creating compatible device drivers for Linux"
http://www.reactivated.net/weblog-conte ... se-0.2.txt

So Linux kernel developers reverse-engineered Windows USB drivers, and now ROS developers port Linux drivers "back" into ReactOS

[Z98]

When it comes to drivers, a "port" is effectively a rewrite. The Linux devs reversing Windows USB drivers was to figure out the protocol such devices were using I believe, not so they could use any code in the drivers. And note that the need to reverse it by definition means there's not going to be much, if any, code sharing going on, since they did not have the source code to begin with. It would generally be easier to just look at a piece of hardware's specifications and write a driver from scratch. The only useful information a Linux driver could provide is if there's something missing in the spec that the Linux devs have discovered and they incorporated a workaround. But that workaround would still have to be rewritten against the Windows driver API. It is, conventionally, very difficult to port an already existing driver to another OS architecture. The only way to "share" significant amounts of code is to isolate all of the code that works on the device and the code that handles I/O through the OS from each other. But this must be done at the start of development. Trying to do it afterward is again, a rewrite.

[hto]

I heard about some projects which aim to help with driver porting / reusing…

[Mna.]

Z98, thank you for reply.

Yes, in fact there are only few reasons to port drivers from somewhere:

• 1. unknown hardware specification - then looking up to implementation we acquire necessary knowledge

• 2. hard problems with hardware, f.ex. "quirks" type problems of Linux - or when several devices communicate each with other, making overall behavior difficult to debug

• 3rd reason could be called "architectureal experience gaining" - learning on foreign implementation in particular OS, to avoid coincidence with the same problems in ROS.

So far, the first point is inevitable, since many devices have closed source device driver for Windows - and many of them are now get their OSS counterpart, and only way to reimplement it in ROS is to either "port" it, or "rewrite" it such or other way.

[Mna.]

I heard about some projects which aim to help with driver porting / reusing…

Could you please remember some references or links on that?... It's just became interesting to me

[hto]

> Could you please remember some references or links on that?

Some links to some driver-related projects were posted on this forum or on ros-dev ML. I do not remember details, will try to search…

Also, I remember talks about using Linux and BSD drivers in GNU Hurd on their mailing lists (using some glue project, which itself can be ported to different OSes). I don't know, can it be helpful here, or not.

[Mna.]

Interesting news
TheRegister: Intel teaches machines to build own device drivers /Game theory versus clumsy coders/

Intel Labs is working to automate the tedious and error-prone process of writing device drivers and porting them to different operating systems.

Explaining the need for a tool that could synthesize device drivers, Intel Labs software engineer Arun Raghunath told The Reg: "A bunch of studies have shown that the prime cause of crashes in operating systems are device drivers. They're notoriously hard to get right."
...

(Russian translation)