Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

It's common practice to deliver Linux kernel drivers (kernel objects KOs) in the source code, and build and install them on the target computer. For example NVIDIA display drivers and Oracle VirtualBox guest add-on drivers are installed this way. It is also common to receive new versions of the kernel (with appropriate headers) through system update. This requires the KO to be re-built and re-installed, otherwise the device will stop working after update.

In our product installation startup script we want to add the step to make and install the KO on every boot. The user may choose to opt-out, and would have to build and install the KO manually. The device driver communicates with a USB device.

Pertinent Details:

  1. The actual re-build will happen only once when the new kernel is installed, because make will not try to re-build the file that is already there and up-to date.

  2. It takes about two seconds to rebuild the driver, and milliseconds to skip the build during the normal boot (not after kernel update)

  3. In the unlikely event that the build fails, it should not crash the system or make it unstable. However our hardware device will not work.

  4. Some distributions may allow to register hooks, to do actions on certain events, like kernel update. However, we are trying to implement something that will work on the most of the distributions in the uniform way. Our installer is script+tar or script+rpm. Unfortunately for this release we do not have bandwidth to prepare native packages for all the distributions (for example Debian-style).

Questions:

  1. Is this an acceptable solution? If not, why?

  2. What are the potential risks associated with this approach?

  3. What the correct/preferred place to run make during startup? rc.local or script under init.d or other? The goal is to make it work on the most of the distributions using the same method (if at all possible).

share|improve this question
    
Might be totally unworkable, but can you not do this via grub options, then have 2 grub entries, one that'll trigger the build and one that wont ? –  Sirex Oct 28 '10 at 7:19
add comment

1 Answer

up vote 0 down vote accepted

This correct answer was provided by Rosco on ServerFault yesterday.

  1. Yes, but you should add a clear howto describing the way we can run your script manually so we can make sure the script will return normally. In the case of VirtualBox in CentOS they add a script in /etc/init.d called vboxdrv:

    /etc/init.d/vboxdrv {start|stop|stop_vms|restart|force-reload|status|setup}
    

    This is clear; we can start/stop the script and get its status, so the risk of getting problems at reboot time is minimal as long as we can check the script on a new kernel before deploying it. You cannot have more standard than this, for me it's perfect.

  2. Systematical failure of the compile process and no module available. Is it this tragic? I don't think so. As long as your script doesn't hang the machine and you give a complete log of the compile failure in /var/log/mymodule, you cannot do better than that.

  3. See 1. - on CentOS/RHEL/Fedora) the vboxdrv runs from /etc/init.d/vboxdrv and checks the distribution name, then source some scripts accordingly. /etc/init.d is the first place I check when I want more informations about a daemon. It's fine with me.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.