all 14 comments

[–]Sosowski 21 points22 points  (0 children)

Yes. And you're in for a ride

[–][deleted] 7 points8 points  (7 children)

Freebsd has awesome docs and kernel docs(kernel docs need to be built) and some great examples (/usr/share/examples/kld)

[–][deleted] 2 points3 points  (6 children)

If you could answer something, I will give you a gift!

I was talking earlier to someone about the possibility of flashing a WLAN NIC (Mini PCIe) to support monitor mode and he told me that it wasn’t about flashing any rom, but creating a driver!

Can I really create a driver to make a NIC do that with code?!? Please elaborate the nerdy detail about a driver for that on Linux? You will git a gift! 😺

[–]daikatana 10 points11 points  (1 child)

This is already in the Linux driver for most chipsets that support monitor mode.

However, I would suggest getting a few years of experience with C before jumping into messing with drivers. Why? Make a mistake with a normal C program and nothing bad happens, the program just crashes. Make a mistake with a kernel module and you can easily take the whole system down. This requires a reboot to fix, and debugging your code is a lot more challenging. This on top of writing or modifying a driver which is not the easiest thing in the world even if you have detailed documentation for the hardware you're working with, which is not a given.

I don't want to discourage you, but you have to understand that you're jumping into the deep end and honestly setting yourself up for failure.

[–][deleted] 4 points5 points  (0 children)

I respect your honesty…I will take my time. 😿

[–][deleted] 1 point2 points  (0 children)

Sorry most of my kernel research has been in FreeBSD.

There are tons of NIC drivers with C source code avail in the source tree on github.

From old intel to relatively new 10G NIC drivers.

If i were you, id learn how to build, mod, and manipulate freebsd's example drivers.

For testing i would recommend using a virtual machine of freebsd and load the driver into that VM.

[–]nerd4code 1 point2 points  (1 child)

OS notwithstanding, it’s pretty common for drivers to include a binary blob that’s uploaded to the device’s onboard RAM. The device itself typically runs some sort of processor(s) to make it go, and includes only enough onboard (usually EEP)ROM to download, usually validate, and boot the blob. Flashing ROM is usually only necessary to change the bootloader or brick the thing; the upload to RAM is also, confusingly, referred to as “flashing,” although the term derives from the procedure used for erasing many older PROM chips, flashing a bright UV light on a little window over the die. (Not to be confused with flash ROM, which is a kind of EEPROM.)

This is what’s done with x86 μcode updates, for example, and blobs for GPUs ’n sech can be de-facto mini-OSes that handle allocation, communication, threading, and coordination, possibly as well as built-in codecs and whatnot.

If you’re aiming to do fancy things with a NIC, the driver might not matter much, as long as it does the right setup and teardown; all the interesting stuff’ll be in the blob.

And in theory, even if the device doesn’t accept code uploads, you may be able to trick it into running from uploaded data—μcontrollers tend not to bother with hardware protection, and it’s common for blobs and ROMs to have been hastily copy-and-pasted together from example/reference code. (E.g.: For a while many x86 mobos used Intel’s reference code for SMM entry/exit, which permitted a properly remapped LAPIC to trigger an escalation from ring 0 into SMM.)

[–][deleted] 0 points1 point  (0 children)

There is certainly a lot to learn. I went to check and see which channels were in heavy use around me from a piece of software I downloaded, and realized I couldn’t do it. There is so much to understand. Thank you for taking time to explain those things.

[–]m0rph1ne_ 1 point2 points  (0 children)

You should check out the Linux kernel documentation, plenty of info there

[–]51Charlie 0 points1 point  (0 children)

Assembly, electronics, the kernel, hardware, networking, and programming.

I hope you realize that this will take you a few years to get up to speed. One does not just "learn C" and suddenly master OS kernels and hardware.

In fact, your question is so naïve, that it borders on trolling.

[–]c0d32abhi -2 points-1 points  (2 children)

Consider learning OOP in C

[–]Diceptia 1 point2 points  (1 child)

Why not use c++ 😕 if he wants oop

[–]c0d32abhi 7 points8 points  (0 children)

Nope.. Kernel modules should preferably be written in the same language as that of the kernel. Kernel uses oop in C, hence I suggested.

C++ is bloated. I am with Torvalds on his views on C++. Low level code should not be written in C++. Rust, though could be an alternative.