Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added automatic driver loading #469

Merged
merged 3 commits into from
Jul 22, 2017
Merged

Added automatic driver loading #469

merged 3 commits into from
Jul 22, 2017

Conversation

Zeerix
Copy link
Contributor

@Zeerix Zeerix commented May 28, 2017

When the config file sets enable_autoload_drivers=1, the installer will
enable driver loading on hotplug events using mdev.conf, and it will try
to load drivers for already connected devices.

With enable_autoload_drivers=1, you don't need to name a specific driver with the drivers_to_load variable to install over wireless.

Tested on both RPi2 (USB WLAN Stick) and RPi3 (onboard WLAN; need another PR to make that work).

When the config file sets enable_autoload_drivers=1, the installer will
enable driver loading on hotplug events using mdev.conf, and it will try
to load drivers for already connected devices.
@goranche
Copy link
Contributor

I'm not sure I see the need for this functionality from an installer like this.
the main issue will still remain, namely the need for separate kernel modules "baked into" the install image, which is not a feasible option if we want to keep the install image as small as possible.

@Zeerix
Copy link
Contributor Author

Zeerix commented May 28, 2017

To make life easier for the user:

Tell me, which driver do I need to load for my USB Wireless Stick I just bought?

Or,

what's the name of the wireless chipset on the RPi 3?

The driver modules need to be compiled for the kernel anyway, and we just put the most common into the installer package: realtek, broadcom, ...

Then it will "just work".

@goranche
Copy link
Contributor

it only "just works" if there are enough modules available... and then you get to the point where you're shipping a lot of modules which will never be used, just because maybe someone somewhere...

the hardware on these devices is known in advance... so for the pluggable ones, supporting "just the most common ones" will open the gates for "but why not this one" type of issues / request (already seen in the topic on WiFi support)... who is to decide what gets included and what not? who will follow trends on the market to add various drivers?

I think this issue needs a better solution, enabling automatic module loading IMHO isn't the right approach, as it solves only one (small and easy) part of the problem.

@Zeerix
Copy link
Contributor Author

Zeerix commented May 28, 2017

But we already ship all wireless modules that are in the kernel package.
What's the downside of loading them automatically?

@goranche
Copy link
Contributor

hm... interesting... they shouldn't be (and aren't in the master / 1.0 branches)...

have to look into this

@Zeerix
Copy link
Contributor Author

Zeerix commented May 28, 2017

The 1.0 branch doesn't have support for wireless anyway.

And the 1.1 branch already had all wireless modules included when I started using the installer (about 2 years ago).

I don't see a reason to remove not to include them.
A completly different issue are all the firmware files. That's probably a lot of megabytes. I would only include those from official Raspberry devices, for example the onboard WLAN from Rpi 3 and Zero W.
And then have a way to extend the installer by the user (plugins?).

@goranche
Copy link
Contributor

there were quite a few discussions, and including modules was one of the topics... (obviously because of size concerns)
I didn't really check on this project in quite some while now, but it seems it was obviously decided that they would be included. will have to check things out, get up to speed

if the modules are available (as they seem to be), of course, it makes sense to have auto loading enabled. 👍

@Mausy5043
Copy link
Contributor

Assuming we are moving towards a merge (I'm not sure). Could you also provide a change to the documentation?

@Zeerix
Copy link
Contributor Author

Zeerix commented Jun 6, 2017

Assuming we are moving towards a merge (I'm not sure). Could you also provide a change to the documentation?

Sure, can do.

However, since I found other projects doing it this way, I tend to remove the switch and just enable it by default.

@Mausy5043
Copy link
Contributor

So, what's it gonna be then? :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants