Re: Seeking advice on "monkey patching" a driver
On Thu, Jul 01, 2021 at 03:03:12PM -0500, Ian Pilcher wrote: > On 7/1/21 12:59 PM, Greg KH wrote: > > Oh that's horrible, please no, do not do that :) > > Indeed it is, but it works, and it meets my main objective, which is to > allow the use of distribution kernel packages and modules. > > > How about a third option, the correct one: > > - submit your code changes upstream and they get merged into the > > main kernel tree and no monkeypatching is ever needed at all! > > > > Have you submitted your changes upstream to the existing drivers? What > > is preventing that from happening today? > > There are a couple of reasons that I've never attempted to do this. > > * Scope of work - Currently, there is simply no mechanism to call an LED > trigger from the ahci or libahci modules, presumably because this is > something that really ought to be done by the hardware. So I would > have to add some sort of generic framework to associate LED triggers > with AHCI ports. > > I probably also don't really have the knowledge to do this. I am not > familiar with locking, memory management, etc. in the kernel. Just > because my "hack" works on a specific 2-core NAS doesn't mean that it > won't cause all sorts of breakage on a higher-performance system with > more parallelism. Why are ahci devices somehow "special" here? Just add a trigger to the ahci core for LEDs and all should "just work". We've done that for many subsystems already. > * (Probable) lack of upstream interest - As I mentioned, disk activity > LEDs really ought to be handled by the hardware. I don't know of any > other system that suffers from this particular limitation. So this > is a very, very niche use case. (Most users of this hardware use the > manufacturer's "firmware".) Are you sure we don't already have LED triggers for disk activity? Have you tried the ledtrig-disk.c driver? It says it works on ATA devices, no reason it can't also work for other device types. > I did ask about this on the linux-ide mailing list long ago when I > first wrote the modules, but I don't think that I ever received a > response, which reinforces my belief that upstream isn't likely to be > receptive. > > I've invested significant time in kernel patches in the past, only to > see them ultimately not be accepted, so I would need to know that > upstream was truly interested in such a feature before I would consider > making such a commitment. That's not fair, there is no way anyone can promise anyone that their patches will be accepted, _before_ anyone sees them. What would _you_ do if you were in the kernel maintainer's position and read something like this? good luck! greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: laptop iwlwifi suddenly not working
Maybe there’s a hardware switch that toggles airplane mode? Might not be, since I’d think that would be kind of redundant if there’s a fn key dedicated to it, but I remember my previous laptops had a physical slider switch for airplane mode. Might be worth checking to see if your laptop has one and if it was accidentally toggled. Connor ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: laptop iwlwifi suddenly not working
On Thu, Jul 1, 2021 at 3:49 PM wrote: > > while fumbling to pause grub during boot, > I think I managed to disable the wifi. > and booting a live usb gets same result ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
laptop iwlwifi suddenly not working
while fumbling to pause grub during boot, I think I managed to disable the wifi. its affecting distro kernel, and my own booting with iwlwifi.debug=0xff on command line shows me iwl_pcie_apm_init Init card's basic functions reporting RF_KILL (radio disabled) It is reading that from somewhere, but where ? F12 has radio-beacon icon, pressing it causes WM to show Airplane mode, so that appears to be the rfr-kill switch dmesg -w shows me bluetooth going on and off, but no try to do so on iwlwifi are there other rf-switches ? I also tried reboot, F2 - (uefi bios) reset factory, reboot that obviously didnt help FWIW this laptop exhibits pcie correctable errors, I have pci=noaer in my boot line to ignore it. too long ? iirc, it was on same pcie port removing it doesnt help now, ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Seeking advice on "monkey patching" a driver
On Thu, Jul 1, 2021 at 2:03 PM Ian Pilcher wrote: > > On 7/1/21 12:59 PM, Greg KH wrote: > > Oh that's horrible, please no, do not do that :) > > Indeed it is, but it works, and it meets my main objective, which is to > allow the use of distribution kernel packages and modules. > > > How about a third option, the correct one: > > - submit your code changes upstream and they get merged into the > > main kernel tree and no monkeypatching is ever needed at all! > > > > Have you submitted your changes upstream to the existing drivers? What > > is preventing that from happening today? > > There are a couple of reasons that I've never attempted to do this. > > * Scope of work - Currently, there is simply no mechanism to call an LED > * (Probable) lack of upstream interest - As I mentioned, disk activity >LEDs really ought to be handled by the hardware. Are LEDs really that important? Unless theyre rigged intrinsically into the operation, it seems tertiary I don't know of any >other system that suffers from this particular limitation. So this >is a very, very niche use case. (Most users of this hardware use the >manufacturer's "firmware".) > >I did ask about this on the linux-ide mailing list long ago when I >first wrote the modules, but I don't think that I ever received a >response, which reinforces my belief that upstream isn't likely to be >receptive. > theres a firehose of patches. FWIW, now robots watch the list, and will grind your patches on lots of configs. arches > I've invested significant time in kernel patches in the past, only to > see them ultimately not be accepted, so I would need to know that > upstream was truly interested in such a feature before I would consider > making such a commitment. > no guarantees, but there is staging. (here, more or less) provisional home for code while quality develops once youre in-tree, warts and all (to some extent, I dont know) you may well get help (patches) improving it, surely lots of feedback. elsewhere, nobody knows it exists. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Seeking advice on "monkey patching" a driver
On 7/1/21 12:59 PM, Greg KH wrote: Oh that's horrible, please no, do not do that :) Indeed it is, but it works, and it meets my main objective, which is to allow the use of distribution kernel packages and modules. How about a third option, the correct one: - submit your code changes upstream and they get merged into the main kernel tree and no monkeypatching is ever needed at all! Have you submitted your changes upstream to the existing drivers? What is preventing that from happening today? There are a couple of reasons that I've never attempted to do this. * Scope of work - Currently, there is simply no mechanism to call an LED trigger from the ahci or libahci modules, presumably because this is something that really ought to be done by the hardware. So I would have to add some sort of generic framework to associate LED triggers with AHCI ports. I probably also don't really have the knowledge to do this. I am not familiar with locking, memory management, etc. in the kernel. Just because my "hack" works on a specific 2-core NAS doesn't mean that it won't cause all sorts of breakage on a higher-performance system with more parallelism. * (Probable) lack of upstream interest - As I mentioned, disk activity LEDs really ought to be handled by the hardware. I don't know of any other system that suffers from this particular limitation. So this is a very, very niche use case. (Most users of this hardware use the manufacturer's "firmware".) I did ask about this on the linux-ide mailing list long ago when I first wrote the modules, but I don't think that I ever received a response, which reinforces my belief that upstream isn't likely to be receptive. I've invested significant time in kernel patches in the past, only to see them ultimately not be accepted, so I would need to know that upstream was truly interested in such a feature before I would consider making such a commitment. -- In Soviet Russia, Google searches you! ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Seeking advice on "monkey patching" a driver
On Thu, Jul 01, 2021 at 11:25:49AM -0500, Ian Pilcher wrote: > I maintain a couple of out-of-tree modules that enable "mainstream" > distributions to be used on the Thecus N5550 NAS. > > https://github.com/ipilcher/n5550/tree/master/modules > > The disk activity LEDs in this NAS are software controlled, so the > n5550_ahci_leds module exists to "inject" a wrapper around libahci's > qc_issue() function which triggers the correct LED (if any). > > > https://github.com/ipilcher/n5550/blob/25538096fffd7942be8b7f2c66af580620a422b6/modules/n5550_ahci_leds.c#L225 > > It's certainly a hack, but it makes use of the modules much simpler, as > there's no need to patch and rebuild libahci, override the distro- > provided module, etc. As long as modprobe is configured to load > n5550_ahci_leds immediately after libahci and before any consumers of > libahci are loaded, things "just work". > > The current version of n5550_ahci_leds attempts to ensure that no > libahci consumers are loaded before it modifies libahci's > ahci_ops.qc_issue. It does this by: > > * locking module_mutex > * getting a reference to the libahci module (with find_module()) > * checking libahci's reference count > * grabbing a reference to *itself* to prevent itself from being > unloaded > * modifying ahci_ops.qc_issue > * unlocking module_mutex Oh that's horrible, please no, do not do that :) > (There similar logic in the n5550_ahci_leds_enabled_store function to > reverse the modifications, if no other libahci consumers are loaded.) > > It's very possible that some or all of these precautions are > unnecessary (or that they're inadequate). I am most definitely not an > expert at kernel development or the details of the kernel's module > loading mechanism. I and few others have, however, been successfully > using these modules for a number of years. > > I've just discovered that neither module_mutex nor find_module() are > available in recent kernels, and I'm unsure how to proceed. The two > options that I've been able to think of thus far are: > > * YOLO! I can simply remove the checks from the module and rely on user > space to ensure that n5550_ahci_leds is loaded before any libahci > consumers load (i.e. before udevd starts). > > * kprobes - I have a feeling that this is the "correct" way to do this > (and it would have the benefit of working even if libahci or its > consumers aren't built as modules). OTOH, it isn't clear how I would > go about accessing the arguments passed into the function without > JProbes, and I'm not thrilled with the idea of adding additional > overhead and/or locking to the disk I/O path. How about a third option, the correct one: - submit your code changes upstream and they get merged into the main kernel tree and no monkeypatching is ever needed at all! Have you submitted your changes upstream to the existing drivers? What is preventing that from happening today? thanks, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Seeking advice on "monkey patching" a driver
I maintain a couple of out-of-tree modules that enable "mainstream" distributions to be used on the Thecus N5550 NAS. https://github.com/ipilcher/n5550/tree/master/modules The disk activity LEDs in this NAS are software controlled, so the n5550_ahci_leds module exists to "inject" a wrapper around libahci's qc_issue() function which triggers the correct LED (if any). https://github.com/ipilcher/n5550/blob/25538096fffd7942be8b7f2c66af580620a422b6/modules/n5550_ahci_leds.c#L225 It's certainly a hack, but it makes use of the modules much simpler, as there's no need to patch and rebuild libahci, override the distro- provided module, etc. As long as modprobe is configured to load n5550_ahci_leds immediately after libahci and before any consumers of libahci are loaded, things "just work". The current version of n5550_ahci_leds attempts to ensure that no libahci consumers are loaded before it modifies libahci's ahci_ops.qc_issue. It does this by: * locking module_mutex * getting a reference to the libahci module (with find_module()) * checking libahci's reference count * grabbing a reference to *itself* to prevent itself from being unloaded * modifying ahci_ops.qc_issue * unlocking module_mutex (There similar logic in the n5550_ahci_leds_enabled_store function to reverse the modifications, if no other libahci consumers are loaded.) It's very possible that some or all of these precautions are unnecessary (or that they're inadequate). I am most definitely not an expert at kernel development or the details of the kernel's module loading mechanism. I and few others have, however, been successfully using these modules for a number of years. I've just discovered that neither module_mutex nor find_module() are available in recent kernels, and I'm unsure how to proceed. The two options that I've been able to think of thus far are: * YOLO! I can simply remove the checks from the module and rely on user space to ensure that n5550_ahci_leds is loaded before any libahci consumers load (i.e. before udevd starts). * kprobes - I have a feeling that this is the "correct" way to do this (and it would have the benefit of working even if libahci or its consumers aren't built as modules). OTOH, it isn't clear how I would go about accessing the arguments passed into the function without JProbes, and I'm not thrilled with the idea of adding additional overhead and/or locking to the disk I/O path. I'd really appreciate any thoughts, advice, ideas, links etc. Thanks! -- In Soviet Russia, Google searches you! ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: kernel build error during ubuntu linux kernel build
On Thu, Jul 1, 2021 at 4:03 AM wrote: > > > Hello Alexander Kapshuk, > > Thanks for the reply. Following your advice, I installed `sudo apt install > zfs-dkms` ( it gave me this scary-looking warning below I just installed > it, because I’ll not distribute anything) > > It installs sources for zfs-dkms and I understand it contains bash script > to automatically compile it when the kernel changes. > > I later found I had to do these commands. > > > > export $(dpkg-architecture -aarm64); export > CROSS_COMPILE=arm-linux-gnueabihf- > > LANG=C fakeroot debian/rules ARCH=arm64 > CROSS_COMPILE=aarch64-none-linux-gnu- clean > > LANG=C fakeroot debian/rules ARCH=arm64 > CROSS_COMPILE=aarch64-none-linux-gnu- binary-headers binary-generic > binary-perarch > > > > Before this, I had to download > gcc-arm-10.2-2020.11-x86_64-aarch64-none-linux-gnu > from > https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-a/downloads > because I saw some compiler error related to STACKPROTECTOR compile option > when I used gcc tool from linaro which was based on gcc 7.5 (I remember, > the new toolchain is gcc 10.2 based). > > With these, I could finally compile ubuntu 20.04! > Great to hear. Thanks for letting us know. > (For those interested, please see > https://unix.stackexchange.com/questions/656263/how-to-build-ubuntu-for-arm64-how-to-give-arch-and-cross-compile-variable-to > ) > > > > Thank you! > > Chan Kim > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
