ostroproject / ostro-os

Ostro OS
Other
93 stars 43 forks source link

Autoload i2c-dev module on boot #21

Closed brunobottazzini closed 8 years ago

brunobottazzini commented 8 years ago

Soletta needs the module i2c-dev[1] to be up on boot in order to use i2c.

We have tested it in a Galileo Gen2 confirming this modules won't loading at boot time.

[1] - https://www.kernel.org/doc/Documentation/i2c/dev-interface

msivosuo commented 8 years ago

@jlaako - could you comment, thanks!

jlaako commented 8 years ago

You could load the modules at the same time as loading Soletta? Add modprobe to Soletta .service file if necessary.

brunobottazzini commented 8 years ago

@jlaako, Wouldn't this be an alternative solution?

Thinking that Ostro was made to be for iot devices and for sure others frameworks might depend on i2c-dev module?

Is there any problem to have this module loaded ?

brunobottazzini commented 8 years ago

Hey @jlaako, have you got any update about this ?

Regards,

ipuustin commented 8 years ago

In my opinion the kernel module configuration should be a) dynamic b) minimal. Especially in production many people won't likely use i2c-dev. I would rather load the module when needed rather than automatically. You could also drop a configuration file to /usr/lib/modules-load.d/ from your recipe to make systemd-modules-load load i2c-dev module during boot.

mbelluzzo commented 8 years ago

So why you have spidev automatically loaded?

mythi commented 8 years ago

@mbelluzzo On Galileo at least it isn't (just checked).

mbelluzzo commented 8 years ago

I checked on Edison and it was there.

On Fri, Apr 1, 2016, 03:30 Mikko Ylinen notifications@github.com wrote:

@mbelluzzo https://github.com/mbelluzzo On Galileo at least it isn't (just checked).

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/ostroproject/ostro-os/issues/21#issuecomment-204268832

thiagogcm commented 8 years ago

Sorry for the silly question, I've just started using Ostro and I need the i2c (using sensor htu21d). How can I manually load the i2c-dev module ?

brunobottazzini commented 8 years ago

@thiagogcm, to use i2c-dev module you should type:

modprobe i2c-dev

To see what module is loaded type:

lsmod

thiagogcm commented 8 years ago

Awesome. That works! And giving my humble opinion, I think it should be loaded at boot time. At least in my case I wasn't expecting that it would be disabled by default.

brunobottazzini commented 8 years ago

Any news on this issue ?

yongli3 commented 8 years ago

@brunobottazzini FYI, we are discussing this issue in the below: RFC How to perform the pre-settings before use I2C IIO nodes https://lists.ostroproject.org/pipermail/ostro-dev/2016-April/date.html

mythi commented 8 years ago

@brunobottazzini In the mean time, I'd propose this gets addressed in meta-soletta/soletta by adding a modules-load.d .conf or doing the modprobe like @jlaako suggested.

I'm closing this

brunobottazzini commented 8 years ago

@mythi, alright will do.

Thanks

yma11 commented 8 years ago

@brunobottazzini why is this issue closed? since the ticket in Ostro Jira is already closed, we will have no way to track if this issue closed too. Thanks, Yan.

brunobottazzini commented 8 years ago

@yma11, I don't know. @mythi has closed it.

I don't have the permissions to reopen it. If someone could do this that would be great :)

barbieri commented 8 years ago

I've mixed feelings about this. What @ipuustin said makes sense, not all products depend on it. however that also applies to soletta: not all users will want that, just people using i2c modules... but the API is always present, so there is no need/way to "declare you want i2c". And pushing this to the application to add that file is cumbersome.

That said, what if we enable i2c-dev automatically if the kmod is built. To disable that where products do not want they disable the kmod in kconfig fragments. It is likely that products will disable stuff they do not want and will add what they do as built-in. After all our kmod selection is too broad, currently adds hundreds Megabytes to image.

The devtool is supposed to help the user doing that exact task see https://github.com/ostroproject/meta-ostro/pull/89

kad commented 8 years ago

disabling module doesn't make sense on kernel level most of the times. unless really custom bsp is build for very specific device. Dynamic configuration is better. might be not via soleta recipes, but better to install those "load module xyz" via special small recipes that people can switch on/off on image building level if desired. our development images better to ship with spi-dev, i2c-dev and similar helpful for makers.

barbieri commented 8 years ago

what I said is that kmod-i2c-dev recipe is to install that file. If you blacklist that module, so it doesn't end in the final image, then you also remove the modules-load.

barbieri commented 8 years ago

not to say you can also blacklist/install-/bin/true in modprobe.d/disable-i2c-dev.conf

mythi commented 8 years ago

On Thu, Apr 14, 2016 at 8:21 PM, Gustavo Sverzut Barbieri < notifications@github.com> wrote:

That said, what if we enable i2c-dev automatically if the kmod is built. To disable that where products do not want they disable the kmod in kconfig fragments. It is likely that products will disable stuff they do not want and will add what they do as built-in. After all our kmod selection is too broad, currently adds hundreds Megabytes to image.

This goes back to the original question. From Ostro perspective this would mean we always load it. It's easy to append to KERNEL_MODULE_AUTOLOAD and that gives the modules-load.d .conf files.

To better match the "not all products depend on it", the proposal was to have soletta install that .conf. However, it's true the end result is the same (all Ostro images get it).

The ideal case indeed is every module gets it's own package and comes with the modules-load .conf file if installed. My proposal as the short term workaround would be to have it with soletta_git.bb. Just like meta-soletta was doing with '''lss'''.