Closed brunobottazzini closed 8 years ago
@jlaako - could you comment, thanks!
You could load the modules at the same time as loading Soletta? Add modprobe to Soletta .service file if necessary.
@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 ?
Hey @jlaako, have you got any update about this ?
Regards,
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.
So why you have spidev automatically loaded?
@mbelluzzo On Galileo at least it isn't (just checked).
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
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 ?
@thiagogcm, to use i2c-dev module you should type:
modprobe i2c-dev
To see what module is loaded type:
lsmod
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.
Any news on this issue ?
@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
@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
@mythi, alright will do.
Thanks
@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.
@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 :)
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
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.
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.
not to say you can also blacklist/install-/bin/true in modprobe.d/disable-i2c-dev.conf
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'''.
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