communicate with a driver from a kernel module
 

I want to communicate with a driver (/dev device) from a kernel module. I have an application and some kernel modules associated with it. From the lowest KM I want to read and write to the driver. What should I do? I have read that writing and reading files from the KM is not a good choice. Is there any other way? Could I use the header files of the driver? If so, how?

A "kernel module" is simply "part of the kernel," and so is a device-driver. I don't know what you mean by "the 'lowest' KM." Also, don't expect a kernel module to read or write to application files: that's not what it's for.

If you have an application that needs to do things that involve a kernel-module, you probably need to create a daemon (aka "service"), perhaps running with rootly privileges, that acts as a proxy to whatever the kernel-module is supposed to be a part of. Other applications by some means rendezvous with this service process, sending requests to it and receiving results. The service process (or its threads, blah blah) is the one that will be reading and writing those files, operating in user space. It, too, is the one that knows how to talk to the kernel modules, and it's the only process that those modules will listen to.

Now ... before you go much farther with this one ... research this: "hasn't this been done before, by somebody else out there who did a really good job of it, such that I can cabbage some or all of what they did?" Do not do a thing already done. My little alarm-bells are going off right now, telling me that this is probably your situation. :)

Another bit of sage advice ;) is ... "okay, even though I've got this notion stuck in my head of 'how to do this,' what am I actually trying to do, and how many other ways can I think of to 'do this?'" I can say from personal experience that nothing makes you feel more dumb, or to say :banghead; "d-oh!!" most loudly ... :cry: ... than to show-off something complicated to someone who just smiles at you sweetly and says, "but why didn't you just do this, instead?" Or: "why didn't you just use this tool (that you never even bothered to find out existed ...) instead?"

thank you for your consideration
i should explain my work in more details:
actually I want to implement openss7 over Sangoma A104 card. Openss7 is a Stream and I want to communicate with the card driver (Wanpipe) from this Stream. my problem is i do not have a general idea for this. I have worked on this for more than one month and my idea is:
At one hand I should build a Stream based on openss7 and at the other hand I should read and write Wanpipe from the lowest kernel module of the Stream. Wanpipe creates some character devices(/dev) and network devices (interfaces) and as I think I should read and write the network device.What is the best way to read write open and close a char device and a network device from a kernel module? Could I work with a network device via socket programming from a kernel module? As I said I am not sure that my general approach is correct :( If I am completely wrong: I would be very thankful if suggest me another approach.

I would candidly and respectfully say that you're trying to "dumpster dive" to "the lowest level of" the kernel ... to do something that ought to be done by a user-land (perhaps multi-threaded) daemon process. You don't need to use a kernel module to do this.

For example, you can define a user-level library of routines that are to be called by programs that want to interact via Openss7, and these communicate with a set of processes that must always be running, which are using the Wanpipe-based virtual devices to send and receive information as required. The daemon implements the necessary protocol, and for the most part it is device-agnostic.

In other words: "use socket programming" and forget the words, "kernel module."

There are many instances of systems that have been built to have a "system-level" interface which depends upon user-level code. For example, in one (non-Linux) system that I dealt with in the past, the daemon process (which was and had to be privileged) would register itself with the operating system, and when it did so, several virtual-devices would appear that could then be read or written. The operating system buffered this data to the daemon, by means of sockets, and it was the responsibility of that daemon to implement the rather-complicated protocol. When the daemon shut down or became unresponsive, the virtual devices disappeared again.

IBM uses the term, System Control Program (SCP), where we use "operating system," and I submit that this is a much better term because it properly reflects what this layer of software actually does: it controls the system (hardware). Nothing more or less.

thank you again
Openss7 is implemented as a Stream that includes some kernel modules. It works now on some devices as below:

USER SPACE
----------------------------------------------------------------
KERNEL SPACE
--------------
| Stream Head |
--------------
|
|
--------------
| Stream KM1 |
--------------
|
|
--------------
| Stream KM2 |
--------------
|
|
--------------
| Stream KMn |
--------------
|
|
---------
| Driver |
---------
|
|
-----------
| Hardware |
-----------

I want to use it for a new device as:

USER SPACE
----------------------------------------------------------------
KERNEL SPACE
--------------
| Stream Head |
--------------
|
|
-------------
| Stream KM1 |
-------------
|
|
-------------
| Stream KM2 |
-------------
|
|
-------------
| Stream KMn |
-------------
|
|
-------------
| UNKNOWN KM |
-------------
|
|
-------------------
| Driver (Wanpipe) |
-------------------
|
|
-----------
| Hardware |
-----------

Actually I want to work on UNKNOWN KM that at one hand communicate with the Stream modules and at the other hand with Wanpipe driver. I am not going to change the working structure of Openss7. As I said it works for some drivers now but those drivers are Stream drivers. I just want to use it for a new device. Are your ideas still similar to those you said in your last posts? Or is there another approach?
I am very thankful for your answers.

---

Hi,

I am noticing the following errors in the system log file on one of RHEL5 server.. They are occurring once every day since 2/10 starting at roughly at 7:00 AM.

kernel: megasas: build_ld_io error, sge_count = 51
kernel: megasas: Err returned from build_and_issue_cmd
kernel: sd 0:2:1:0: timeing out command, waited 360s
kernel: sd 0:2:1:0: Unhandled error code
kernel: sd 0:2:1:0: SCSI error: return code 0x06000000
kernel: Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT,SUGGEST_OK

I am not sure what could be causing it.Please help me if someone has solved such problem.