Drivers extension for RedPill - request for comments & drivers packages


Recommended Posts

Hello!


TL;DR: We've developed a new loader for v6.2.4/v7+ which contains a way to install custom extensions/drivers/mods. We're looking for feedback of the extension manager & kindly asking for drivers to be made compatible with it.

 

First of all, let us thank you guys for all the driver packages you were always preparing - we used them ourselves. As some of you may be aware we are developing a new loader called RedPill. There's a long thread in the developer's section of the forum:

 

Today we've added a long-awaited functionality of custom drivers. We've chosen to go with a more modular approach rather than offering a clone of Jun's loader functionality of extra.lzma archive. Our solution relies on a simple extension manager which is responsible for downloading and packing drivers automatically. This lets users install only the drivers they need while also mixing-and-matching multiple ones. With "extra.lzma" the limitation was that users either had to build their own packages or choose between having the HBA driver or VirtIO driver... that, in our opinion, was a poor experience. Additionally, the new format allows you to keep a single git repository containing both the metadata for RedPill extension manager and the build environment you use to compile drivers.

 

We would like to collect your opinion on the new extension manager we created and ask you to port your drivers to the new format. We prepared two documents:

 

In addition, we published two packages, which can serve as an example:


There's currently no central way to discover packages but is it planned. For now we're simply collecting links to indexes in a separate git repo - https://github.com/RedPill-TTG/redpill-extensions - you can just toss a link there from the GitHub web UI without cloning the repo.

 

 

What do you all think? ;)

special cc @IG-88

 

p.s. We didn't post this in the driver's extensions subforum as this topic isn't intended for users. When some drivers are built and the official beta version of RedPill is published we will create a separate thread there.

  • Like 5
  • Thanks 8
Link to post
Share on other sites

We think it should be 1 driver = 1 extension. This way you install driver for your ethernet, driver for your GPU, and a driver for your USB 3 chipset. This will also let us do another cool thing down the road: provide a small image which will boot on your hardware, scan it (essentially grab vids & pids), and suggest a platform and drivers needed to make it work. VID & PID info are embedded in the drivers on linux anyway so it's easy to extract. If you pack many drivers in one package you can easily run into conflicts and load way too much. Jun's loader loaded a ton... literally all modules. In a system with just extra.lzma to get virtio we see 178 kernel modules - mptsas, mpt2sas, mp3sas, vmxnet, megaraid... and many many more which have nothing to do with the platform.

Of course, naturally some drivers will have multiple kernel extensions as it makes no sense to separate them. For example VirtIO is technically like 5 drivers but we never saw anyone using just VirtIO-SCSI but not load VirtIO-NET. With some HBAs it may also make sense to make a bundle containing like 3 drivers for LSI cards. But definitely bundling e.g. VirtIO and LSI woudln't make sense. It's a delicate balance :D

 

Same for CPU governor: for example we don't need it at all as we either want performance on a bare metal server-server or run it under a VM. This is why we didn't want to bundle it as many folks will not use it. To be honest the concept of power management on Linux is slightly foreign for all of us as we either lazily use Dells supported by Ubuntu or run Linux on servers which don't really care about PM.

Edited by ThorGroup
  • Like 2
  • Thanks 1
Link to post
Share on other sites

Just for the curiosity of it, I tried making a driver extension for LSI SAS cards adding pocopico compiled mpt2sas and mpt3sas drivers as the seem to work with the correct dependencies. However I haven't got time to test it, so I just toss it in here for anyone to either copy or do with whatever pleases you.

 

Repo

https://gitea.wickenberg.nu/Piteball/redpill-mptxsas

 

Extension JSON index file

https://gitea.wickenberg.nu/Piteball/redpill-mptxsas/raw/branch/master/rpext-index.json

  • Like 1
Link to post
Share on other sites

Nice ! You are the first one !!! I think they need some modifications. 

 

I'm planning to release some more drivers but I wanted to have some time to compile them for 4.4.59 (918+ 6.2.4) and 3.10.105 (918+ 6.2.4).

 

 

Link to post
Share on other sites
15 минут назад, pocopico сказал:

Nice ! You are the first one !!! I think they need some modifications. 

 

I'm planning to release some more drivers but I wanted to have some time to compile them for 4.4.59 (918+ 6.2.4) and 3.10.105 (918+ 6.2.4).

 

 

Extract drivers from jun's extra.lzma and use them?

Edited by Amoureux
Link to post
Share on other sites
Posted (edited)
15 hours ago, Amoureux said:

Extract drivers from jun's extra.lzma and use them?

Even if you forcefully insert them that's a bad idea - you can yolo things in user space but not in the kernel as userspace is guarded by the kernel and kernel is only guarded by a sparse memory managemnt unit checks :D The kernel space has literally no memory protection per se (ok, there are small bits here and there but this is mostly bug-catching and not protection between drivers due to performance reasons). It's a PITA that kernel modules in Linux are specific to that exact version up to the t but that's a small price to pay for a great kernel. That decision was famously made in 1991 (if someone's interested google for Linux vs Minix and now-legendary exchange between Linus T and Minix author - it could be a hollywood movie).

 

This is why RedPill extensions system is VERY specific to the versions of modules so nobody accidentally even try loading wrong driver's version as this is much more dangerous on Linux than on Windows or macOS. Drivers on Linux are literally running on the same privilege level as the kernel itself. On macOS more and more are in userspace or are at least partially isolated. This is why nobody should experiment with e.g. SAS drivers on a drive with data which they care about [unless tested by many and confirmed working properly].

Edited by ThorGroup
  • Like 2
Link to post
Share on other sites

My current understanding is that an extension bundles one or more main driver and their dependencies. The "kmods" item in a recepie decleare the load order of the modules for this extension during boot. 

 

If the dependencies are not supposed to be included in an extension, is there a mechanism in place to defince dependencies to other extensions? I assume this would require a dependency graph/tree detection, which I assume is highly messy or even imposible to archive with plain bash. 

Edited by haydibe
  • Like 1
Link to post
Share on other sites
On 10/1/2021 at 9:15 PM, pocopico said:

@ThorGroup Some text files have been created on the extensions repository. I only have a question, how are the modules loaded ? How do you take care of the dependencies ? Should i also create a script for loading the modules ?

There's a script which takes care of that. Its template is present in redpill-load repo in include/loader-ext/target_exec.sh_ - it is filled-in with by the extension manager.

From the perspective of adding new drivers you should just add entries under kmods key like described in the documentation for devs and the target_exec script will take care of the rest (i.e. insmodding them etc).

 

There are no interextension dependencies (i.e. between multiple extensions). However, when you specify multiple .ko to load in kmods key they're loaded in that order. There's a mechanism to force extensions load order (extensions key in user_conf as described in dev docs for extensions) as a stop-gap. This should be rare however as drivers loading is for the most part asynchronous in linux anyway.

 

 

On 10/2/2021 at 6:48 PM, haydibe said:

My current understanding is that an extension bundles one or more main driver and their dependencies. The "kmods" item in a recepie decleare the load order of the modules for this extension during boot. 

 

If the dependencies are not supposed to be included in an extension, is there a mechanism in place to defince dependencies to other extensions? I assume this would require a dependency graph/tree detection, which I assume is highly messy or even imposible to archive with plain bash. 

Spot on: dependency graph is needed for that. It would TECHNICALLY be possible in bash but oh boy... that's insane in a very wrong way :lol: Being serious we're planning and preparing for a rewrite of extension manager so that it can support dependencies properly. The current solution is a good-enough PoC to see if the idea will work. We designed it and brainstormed through multiple people to give the community a PoC which is functional (this is probably close to a 10th iteration of the design of extensions itself) but maybe not with all bells and whistles right away.

 

From the perspective of time choosing bash on principle of "it doesn't require installation" was a mistake.

  • Like 2
Link to post
Share on other sites

Question: at what point during the boot process are extension scripts for “enhancements” run, and is there any control over it from user perspective?

 

While trying to diagnose the kernel panic problems I’ve been having with bromolow on baremetal I’ve found that booting with nmi watchdog disabled, but manually enabling it after boot, seems to fix it.

 

I figured I would keep nmi_watchdog=0 in grub.cfg, then use an extension/enhancement script to turn it back on again. Does that sound like an appropriate use of this functionality?

  • Like 1
Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.