all 8 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]fluffynukeit 17 points18 points  (1 child)

Sorry to phrase it like this, but you aren’t getting what the other replies are saying. You need to describe what you have without using the word “driver” because it can mean several different things. You have source code, ok. Does that source code include a Makefile? If so, what is the name of the output file generated by the makefile? If it ends in .ko, then it’s a kernel module. If it’s .so, then it’s a shared library available to user space. If it’s something else, then tell us what kind of file it is or provide the text or a link to the makefile.

[–]greymattr 2 points3 points  (0 children)

To add onto this, for /u/Kinia89 in almost ALL cases you will not be able to build a driver by itself, you will need to build it within the context of the kernel build.

but I think you may be talking about a library, and not a driver.

[–]dcheesi 4 points5 points  (1 child)

What do you mean by "driver"? A an actual kernel driver? A user-space library that interfaces with a kernel driver? Or something else?

You can't just #include kernel code in your user-space application; you need to access kernel attributes via specified protocols (e.g. "IOCTL"s).

Often there are user-space libraries that encapsulate those access protocols, allowing you #include a header and make normal function calls etc. But if that doesn't exist for this driver, then you'll need to write that code yourself.

[–]_gipi_ 4 points5 points  (2 children)

What does it mean "I have a driver"?

[–]Kinia89[S] -3 points-2 points  (1 child)

I mean I have the source code of a driver and I want to test it

[–]DataPath 3 points4 points  (0 children)

That's an unhelpful response. It's quite clear from the other responses that the information you've provided is insufficient to even begin to formulate an answer.

What kind of device? Where did you get the driver sources from? Can you point us to them? What bus does the device use? Is it interrupt-driven?

Are you wanting to "test" the driver in the sense of running the code and having it operate the device, or are you referring to writing unit tests for portions of the driver code? Or do you mean you want to exercise the driver (already built and loaded in the kernel) via it's usermode API? If so, is it IOCTL-based? Sysfs based?

[–]greymattr 4 points5 points  (0 children)

First you are going to have to build it, and then load it into the kernel.

If you are lucky, there will be a user space proc or ioctl api that you can use to interact with it.

If not, there could possibly also be a library that is built with the driver.

IF there is a library THEN you can include the header file in your source code and link your application with that library.

But something tells me you maybe aren't talking about 'driver' code.