Home/ Questions/Q 6635257
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T23:01:54+00:00

In a project I am involved in we have the following hardware setup: Linux

  • 0

In a project I am involved in we have the following hardware setup:

     Linux PC ------> "Router" +----> "Device A"
                               |
                               +----> "Device B"

Linux PC is a standard X86 PC.

“Router” is a piece of hardware we developed that is connected to other pieces of hardware in our system. In this example “Device A”. The “Router” is connected to the Linux PC using USB.

“Device A” and “Device B” are pieces of hardware in the system. They are connected to the “Router” hardware via some communication channel (unimportant in this case).

My task is to write a Linux device driver for “Device A” (and later other devices as well).

I have already constructed a general purpose USB driver that talks to “Router” and this works fine. My plan was to have a driver stack that would look like this:

+----------+----------+
| dev_A.ko | dev_B.ko |
+----------+----------+
|     router.ko       |
+---------------------+
|   Linux USB driver  |
+---------------------+

That is: The device drivers communicate with their hardware using the “router.ko” kernel module which in turn is built on the standard Linux USB driver core.

My problem is that to the Linux PC, there is only one physical device: The “Router” hardware connected via USB, which means the device drivers become some sort of virtual devices.

I could compile teh device drivers and the Router device driver into one big kernel module, but it does not seem like the best solution.

Also, since “Device A” has previously been connected directly to a Linux PC there already exists a driver for it with a well defined userspace-interface which must be kept since there are already applications in production that need to speak to it.

My question more or less boils down to this:

Given the hardware scenario above, how would you structure the Linux kernel modules?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I don’t see any problem with your proposed solution of having one router.ko module that talks to the actual hardware, and submodules dev_A.ko and dev_B.ko that talk to router.ko. You just need to have router.ko export a “my_register_driver” function, analogous to the existing pci_register_driver function. You would pass in a structure that has an “id” member and a “add_device” function pointer; dev_A.ko would pass in id=”A” and add_device=dev_A_add, and similarly for dev_B.ko.

    Then when router.ko comes up, it discovers the hardware and creates virtual devices (your own context structure) for A and B. Then when a submodule comes along, router.ko just calls the appropriate add_device methods with the appropriate virtual device. router.ko should also export methods that the dev_A and dev_B modules can use to access the underlying hardware.

    For an example of what I have in mind, you can look at the mlx4_core, mlx4_ib and mlx4_en modules in the upstream kernel (I wrote them so I choose this example :). The idea with them is that there is one PCI device that can be used as both an InfiniBand and Ethernet device; so mlx4_ib and mlx4_en both use mlx4_core to discover and access the underlying PCI device. The small bit of code that the sub-drivers use to ask for which devices exist is in drivers/net/mlx4/intf.c.

    Also, as far as the existing “Device A” userspace interface, that shouldn’t be a problem. You can just implement the same ABI in your dev_A.ko, unless there is some complication you didn’t mention.

    • 0