When are insmod and mknod not enough?
 

I'm trying to install an open source driver BADDRV on Suse 11, x64 system.

What I have done:
installed kernel source. make. insmod ./BADDRV.ko

On Redhat 5, this just works and I can run the user program that calls open(/dev/BADDRV) and its ioctls.

On Suse 11 there is no entry in /dev so I add mknod /dev/BADDRV c 0 0
The user open(/dev/BADDRV) fails with errno 6.

(I also tried mknod /dev/BADDRV c 244 0, per suggestion of dmesg. No difference.)


There is an rpm provided with the driver. Installing the rpm on Suse 11 works and then the user program works. The only problem with the rpm is that it requires kernel source to be installed, which I can't ask of my customer base.


What else should I do after mknod?
--------

After a reboot dmesg suggested mknod /dev/BADDRV c 248 0. Which works.

So let me change my question. What is this magic number and can I fix it or is it system dependent? Can a bash install script know it and install the driver?

Tear the rpm apart and find out what all operations it's performing. It's just a renamed tar.gz file with specific extras included in consistent places.

...else if the kernel source needs to be installed only to build the LKM, maybe you could prefab the LKM if you have a staging machine or VM guest with the exact same kernel and userland version setup similar to that of the client?

thanks rweaver.

The RPM uses the dynamic major device number. If I use the major number from a terminal prompt or bash script, the driver installs properly and the user application works.