Ask HN: Project ideas for a Linux kernel module
so to that end, What would be a good idea for a linux kernel module I can work on, something that may get me to interact with any topics involving communication standards/protocols ( i2c, SPI, or JTAG, wireless, BLE).
thank you.
[+] [-] pabs3|2 years ago|reply
Along those lines, look at all the dkms modules in any Linux distro and try to talk to the module authors about mainlining, do the work needed if they agree to it.
Also, I have some ideas for Linux kernel things I noticed are needed in my branches of linux.git. I doubt I'll work on them any time soon, so feel free to use the ideas/code I've left in the branches.
https://github.com/pabs3/linux/branches/allNot directly related to your question, but check out the KernelNewbies community and also some of the FOSS internship programs, especially GSoC and LKMP offer paid internships to work on the Linux kernel.
https://kernelnewbies.org/ https://github.com/fossjobs/fossjobs/wiki/resources#internsh...
[+] [-] pablog8|2 years ago|reply
[+] [-] mschuster91|2 years ago|reply
There are a lot of patches that are purely Android-specific and won't ever make it to upstream Linux, but others, like the drivers for flash chips and USB? These could definitely be submitted upstream.
Samsung for example uploads their FOSS dumps to [1].
First thing I'd do is to get u-boot working as a fourth-stage bootloader so you don't have to wrestle with ODIN or fastboot every time you rebuild your kernel. That alone should be a decent sized university project.
[1] https://opensource.samsung.com/uploadList?menuItem=mobile&cl...
[2] https://en.wikipedia.org/wiki/Booting_process_of_Android_dev...
[+] [-] seb1204|2 years ago|reply
[+] [-] jeroenhd|2 years ago|reply
Having an existing community may also be useful for figuring this stuff out.
[+] [-] LeonM|2 years ago|reply
They are great little machines, though a bit underpowered (even when they were new) so running MacOS is not a great experience. Decent Linux support should give these devices a second live.
Most devices should be able to work, as they are all standard components. My suspicion is that we are mostly lacking device trees and maybe some SMC work.
I expect the circuit diagrams for this laptop to be floating around the web somewhere (otherwise shoot Louis Rossman an email), so reverse-engineering the SMC should be doable, and a great low level/embedded challenge.
[+] [-] watmough|2 years ago|reply
Surely most of the required support is there already?
[+] [-] quelsolaar|2 years ago|reply
This could be used for things like user space memory mapping of networked memory, where memory is retrieved from a remote computer when accessed. This would make it possible to transparently implement userspace large scale shared memory systems in a very elegant way. Good luck with what ever you decide to do!
[+] [-] planede|2 years ago|reply
[+] [-] toast0|2 years ago|reply
[+] [-] cushychicken|2 years ago|reply
You'd have to figure out phandle support for the I2C configuration channel, fire up I2S streaming by enabling it in the kernel and piping audio to the DAC, then playing it into some speakers.
Could expand it by adding some filtering. Many DACs have filter banks that you can populate with coefficients via I2C.
There's some decent kernel module resources and examples in this repo if this is something you're brand new to:
https://github.com/Johannes4Linux/Linux_Driver_Tutorial
If you have any interest or experience in cybersecurity and have considered doing that professionally, my company is hiring and likely will be all year. We probably have a use for a new SWE on the embedded side. Email me at my username at Gmail.
[+] [-] megous|2 years ago|reply
But why not I guess. :)
Camera sensor drivers are a bit less abstracted and many sensors don't have upstream drivers. But there's also a lack of quality documentation for HW in this area, oftentimes... v4l2 API is a bit more approachable than alsa PCM API, IMO. And on advanced SoCs you can pass around video buffers bewteen various v4l2 mem2mem devices to transform/process the data in HW. Drivers for HW acceleration of image or video data processing are seldom exercised in all their features, so there are many bugs there waiting to be squashed, and features to be implemented. It's a deep rabbit hole.
[+] [-] mailey|2 years ago|reply
> my company is hiring and likely will be all year. We probably have a use for a new SWE on the embedded side. Email me at my username at Gmail.
I'll keep this mind, thank you.
[+] [-] cies|2 years ago|reply
[+] [-] teleforce|2 years ago|reply
[1] 802.1Q-2018 - IEEE Standard for Local and Metropolitan Area Network--Bridges and Bridged Networks:
https://ieeexplore.ieee.org/document/8403927
[2] Provider Backbone Bridging for Linux:
https://github.com/openss7/pbbr
[3] Are there inherent problems with 802.1aq preventing wider adoption?
https://www.reddit.com/r/networking/comments/8gez0r/are_ther...
[+] [-] whoami_nr|2 years ago|reply
[1]:https://en.wikipedia.org/wiki/Port_knocking [2]:https://rnikhil.com/2016/12/12/port-knocking-python.html
[+] [-] whoami_nr|2 years ago|reply
[+] [-] bugmen0t|2 years ago|reply
This should be somewhat easy to start and self-contained. If you want, you can easily extend it if you want things to become more fancy. E.g., hiding the secret constant. Implementing a challenge response protocol, limiting access to other global state (hardware dongle? ip address?) and so on.
[+] [-] madushan1000|2 years ago|reply
[+] [-] mailey|2 years ago|reply
[+] [-] rsecora|2 years ago|reply
* You can select a board with not fully supported peripheral Examples RISC-V or Loongson boards with incomplete or missing drivers.
* or create a higher abstractions over the SPI for a A/D or D/A or pwm chip. The module offers a /dev/ file that hides the SPI communication or the motor position and encoding...
[+] [-] notthetup|2 years ago|reply
Some SPI devices can stream out lots of data on the bus. I’m looking at you ADCs.
It’d be nice to have a stream style API for that. Not sure which Linux framework is best suited for that. Maybe IIO but something on those lines might be fun to explore.
[+] [-] kuter|2 years ago|reply
I had to first reverse engineer the windows utility that was written in c# and found out that it used wmi commands. After reading the kernel code for a while I realized there where already some code that implemented HP WMI commands.
Using that as a foundation it was quite easy to write my own kernel module that could change the led colors. Then I tried to integrate it with the linux kernel's led API. Since the LEDs where RGB it was a little different to integrate but I managed to find some examples in some playstation joystick driver code.
This project was a lot of fun, but I would say that you should be careful not to break your hardware. I have broken devices even from the user space by pushing it beyond it's limits.
[+] [-] lloydatkinson|2 years ago|reply
[+] [-] raybb|2 years ago|reply
[+] [-] techwiz137|2 years ago|reply
[+] [-] dvh|2 years ago|reply
[+] [-] amadeusz|2 years ago|reply
[+] [-] dokem|2 years ago|reply
[+] [-] Freeaqingme|2 years ago|reply
[+] [-] tyingq|2 years ago|reply
[+] [-] rurban|2 years ago|reply
[+] [-] mailey|2 years ago|reply
[+] [-] dyingkneepad|2 years ago|reply
[+] [-] neoromantique|2 years ago|reply
[+] [-] mailey|2 years ago|reply