NOOB sounding kernel module question

[CentralWare]

What are the Pro's and Con's of compiling a driver WITHIN the kernel as opposed to compiling it as a module?

Take net-usb-KERNEL.tcz for example.

Many of the chips (like the Dx9106/9700/etc.) which function with this extension are reasonably common (considering their price online) thus person "A" may consider it very worthwhile to build the drivers into the kernel and be done with it whereas person "B", who thinks a lot more like I do, says "Why have much of any hardware support INSIDE when you can just load it at boot?  THUS, the inquiry...

[ I'm just Focused on hardware/firmware for this question area to keep things simple ]

• Are there any savings in RESOURCES, FOOT-PRINT, TIME or SPEED compiling internally as opposed to modular?
• If person "A" compiled a kernel to include DRIVER X and person "B" had compiled X as a module (tcz) and the module was installed with the kernel which already had the driver, does "A" or "B" take precedence or would we be causing a panic and we fire both "A" and "B"!!!
• If driver "C" had dependencies such as "A" and "B" (within the kernel or modular) does the kernel know to load dependencies first and/or is there some means of priority needing to be tended to?

I have 18 SD cards I'm trying to create a "universal" boot chip which is applicable for PiZero through Pi3 for this particular test bench where driver "A" is needed for this one and that one, but not the other one and other situations where Extension "Z" isn't available in repo 8.x/armv#/tcz...  (it's instead in 5.x such as nfs) AND I'm mentally preparing for the Arm9 venture likely to be hitting sometime in the near future thus remaking tce-load/config/setup/etc. to help compensate for areas of concern for today as well as ones just to make tomorrow easier, so any NOOB like questions in the next few weeks like this...  bare with me, I'm just planning/thinking ahead!

[curaga]

Built-in takes slightly less space, and if such hardware is present, it is detected faster on boot. Downside is that it uses more RAM, no matter if that hardware is present. For these reasons the common USB chipset drivers are built-in, for example - faster detection of usb sticks on boot, and since most people have USB, there's not much RAM wasted.

The kernel and modules are supposed to match. I don't know what happens if you try to load a module from a different kernel config, that's already built-in to the running kernel.

Dependencies are handled by modprobe, see modules.dep or the module files themselves via modinfo.

[patrikg]

In sand boxing land you should use nfs, it more easy to work with, and don't need the the sd card in/out all time.

I tried to boot up my Original Raspberry Π (the very old one with 256) with nfs with uboot and works very well.
Now even with Raspberry Π 3 have built in to boot with network, without some sd card.

I have done some text files with that...to remember how to do it. I may share it here if this make you happy.
And use uboot and the mac address of the pi to figure out what files being loaded.
So many pis don't load same files, depending what type of pi it is.

Even root was with nfs.
I think i was smart to do the uboot boot cmd like this:

Code: (bash) [Select]

bootcmd 'usb start;setexpr macaddr gsub ":" "" ${ethaddr};env set ethact sms0;env set autoload no;dhcp;nfs 0x02000000 ${serverip}:/home/patrik/picore/${macaddr}.img;source 0x02000000'

[bmarkus]

Built-in modules to support on-chip and on-board hw and core OS features make kernel more reliable on SBC's like Raspberry Pi, like ext4 file system, Ethernet interface, comressed RAM. It makes sure system will boot even if a module mismatched in the initrd.

[CentralWare]

Thank you gentlemen!


@Patrik: I'm considering a blend of NFS, AoE, TFPT and a few other networked filesystems to implement my own "version" of an almost-PXE environment (tiny SD card does nothing more than support the kernel/image and probably dropbear (SSH) and networking drivers such as net-usb, then once the ethernet/wireless is active, run a few scripts similar to PXE which simply mount shares based on the device's MAC, load TCZ extensions within that share (swap /etc/sysconfig/tcedir) and launch scripts found in /mnt/sharename/opt accordingly.  This way, one SD image...  many possible uses per Pi just be changing out the content within the share.

PI Zero: Runs DNSMasq (DNS/DHCP), NTP and a few others 24/7, controls a redundant power supply along with a few dozen or so I2C based relays which act like IP power switches for the other Pi's and managed switches, etc. (allowing the stand-by 5v3A line from the PSU to operate the Zero with everything else completely powered down until needed.)

Atom File Server: Runs TCL x64 with a pair of 1.5TB drives used for the different file systems (work in progress) which is power managed by the Zero as well (remote shut-down and WOL).  This is a temporary machine until I've had time to reprogram a Linkstation to accommodate the same tasks (less foot-print and power that way.)

Thanks again, guys!