I've been messing around with a little app that talks to the IR device driver (/dev/lirc0), and am nearing the point where I'd like to publish it. However, that driver is set up by loading the "lirc_rx51" module.

It is easy enough to just run "modprobe lirc_rx51" as root, but I'd prefer not to force users to do that. The LIRC daemon executes the modprobe call itself when it is started, but it runs with the permissions for that, and I'd prefer not to run my app with elevated permissions. (And my app has no need for the LIRC daemon.) Perhaps it would be best to set up an upstart script to load the module?

I guess I'm asking what the best practices are for managing kernel modules.

Thanks in advance!

don't know, but you could do a command line call from your app, eg:
sudo modprobe lirc_rx51

I think user is always a sudo'er

startup at boot time using init scripts or specific sudo permissions are the things that come to my mind.

I think you should explicitly load it and then unload it, to save memory

Upstart script, where only this script got elevated permissions (via sudoers) seems best practice for me. Yet, 'on close one - if really nothing else is using that module afterwards - that modprobe -r it, would be good practice to.

Ideally, after closing up, Your program should leave device in exact same state, as it was before running Your program (of course, only regarding things related to Your application).

BTW, I'm waiting eagerly for Your idea about IR, so please, don't forget to drop link here (after release), to protect it from being spammed out from 'Active Topics' by harmattan'ish sh|t spam.

/Estel

Thanks, guys! It looks like an entry in the sudoers directory would be a good way to go, then... I would like to unload the module after use, if repeated loading/unloading of kernel modules isn't too much of a burden on the system. Hmm. I suppose I need to do a little experimenting...

Eh, not much of an idea here, really. I just got kinda tired doing things the LIRC way. LIRC is designed to run on a box at which you point a remote control, not a box that is a remote control. So most of its code is involved in receiving, not transmitting, infrared codes. (Which, admittedly, is the harder job.)

There's little point to running a LIRC daemon on the N900, as there's nothing for it to listen to. So, I've "cut out the middleman", by poaching the transmit code out of LIRC and more-or-less pasting it into my own app.

Anyway, I've gotten to the point where I can control some Mac Minis, several Samsung TVs, a Sanyo TV, and a Sony DVD player with it, so I figure its time to clean it up and see if other folks can get some use out of it.

I'll hopefully have something presentable in the next week or two. (Being that this is my first app, I'll be stumbling along for a while figuring out how all this app submission stuff actually works.)

Getting closer now, but still having problems. I've finally managed to construct a debian package for my app, and I've created a couple of little scripts ("loadRX51Module" and "unloadRX51Module") that I've made suid root, that call "modprobe lirc_rx51" and "modprobe --remove lirc_rx51" respectively.

Unfortunately, when running these scripts as the user modprobe still tells me that I lack permission to load the module. If I run the scripts as root, everything works fine...

I've gotta be missing something simple here.

You are not allowed to run root programs like modprobe from a suid script as user. You will need execute rights on modprobe itself in that case (from a suid script: effective user=root, real user=user. That differs from the root user itself) .

maybe creating entry in sudoers (just for scripts that need it explicitly), then calling them with 'sudo' inside program, would be easier approach?

If thats' what you've already tried, and no other idea pops up, sudoers entry for whole program (thus, running it with elevated privileges) would be ugly workaround. Yet, I'm pretty sure our main desired approach is do-able.

You've made garage.maemo.org project? If not, please make source available somewhere, so knowledgeable folks (= not me, probably) could look into Your code and check what may not look as it should.

/Estel

Aha! Thanks, that's what I was missing. Calling the scripts with sudo does the trick. (For some reason, I was thinking that setting the suid bit was the same thing as using "sudo". Maybe I don't need the suid bit at all?)

Indeed I have! I sent a request in for one on Sunday morning, and was kinda surprised that they set one up for me in less than an hour.

Since then, however, I have been kinda flummoxed on how to get my code up to the site. I chose "git" as the source control manager, but am having some trouble using "git push" to upload my code. Unfortunately, it seems that the SSL Certificate for the "vcs.maemo.org" website expired at the end of December, and it hasn't been renewed yet. I've tried to get git to ignore the certificate, but even so, it doesn't seem to want to communicate with the server.

They have an alternate access method via ssh, involving the use of a public key. I've been playing around with that a little bit, but I'm still working my way up the learning curve there.

In any case, the main problem here is my need to learn how the system works. I can see that other projects have been getting updated over the last week, so I know the garage site is still open for business. I just need to buckle down and work my way through all the documentation...

Anyway, the project's name is "Pierogi", and you can find the (currently completely empty) garage site at:

https://garage.maemo.org/projects/pierogi/

EDIT: The reason I wasn't able to upload my code was due to an incorrect password. Arrgh. I get so caught up in the details, I always miss the simple stuff.

Anyway, code is on the way up...