Not all drivers can be built as a module. A big example is that enabling swap memory must be integrated (imagine swapping out memory, and then the driver is unloaded…or for that matter imagine that there could be any possible use of unloading the ability to use virtual memory swap). This is the advantage of menu config style editors…they work with the dependencies and won’t allow setting something which isn’t valid. It isn’t an Xavier or Tegra issue…it’s just that the software was or wasn’t designed to work as a module.
Some drivers without module format could have additional code added to allow module format, but others would be a mess in any attempt to do so.
There are also some advantages in performance (though small) by running integrated instead of via a module.
Thankyou for your response. Note that it does not address the key facets of the question:
Things built as modules on tegra are builtin on xavier. Why?
Things that I personally built as modules on tegra are only available as builtins on xavier. Why?
How do i configure things on Xavier so that I can build things as modules?
Should I not do things as modules on xavier because Bad Things Will Happen?
Given that those of us who have been building kernels since the 2.4 days where super grateful for
the significant expansion of module support in 2.6 it is surprising to suddenly find myself working
with a monolithic kernel again in Dec 2018. What is up with this?
Once again, thankyou for taking the time to respond to me, I appreciate it very much. If you have some concrete and actionable insight into the 5 topics I outlined above, I would love to learn about them!
The Jetson itself does not change whether or not certain drivers or features can be made as a module…that is the nature of the code someone wrote. If someone did not add the code to make a feature possible as a module, then there is no possibility of it being a module without adding the code…Jetson itself has no influence on this. Some feature must also be integrated into the kernel, e.g., swap is highly invasive on virtual memory, and no feature like this is ever built as a module no matter which system it is built for.
There is no issue building as a module for a Jetson which is build-able as a module anywhere else. If this can be a module on x86_64, then it can be a module on Xavier. If the feature cannot be a module on x86_64, then it also cannot be a module on Xavier. The menu-based configuration editors merely reflect this fact and would give the same answer on Xavier or a PC.
There is a very slight performance increase in building a feature as integrated and not as a module…it eliminates a direct branch assembler instruction, but that’s a very trivial time.
Total module content does need to be limited as explained in that original URL, but arm64 is usually not a problem for most setups. Making everything as a module is a problem though.
In most cases I prefer adding modules instead of integrating into the kernel Image. Only a few features don’t allow module format…trust the menu editor, and if modules are not allowed, then there is probably a good reason for it which won’t be due to running on an Xavier.
The module of interest builds as a module on x86_64 and tegra and not on xavier.
To refer to the lsmods that i did on both tegra and xavier, many things that are modules on tegra are not modules on xavier and I am very curious as to why.
I was hoping to see an answer from Dusty but I expect he is fully engaged in shipping the next xavier release and thus does not have time for his usual forum activity.
Does the make menuconfig allow setting as module on one platform, but not the other? If so, then the arm64 architecture probably has a reason for not allowing as a module. If the make menuconfig allows setting as a module, but build fails, then there is a bug in need of repair. I use “make nconfig” because of its ability to look at disabled or not-selected options. Is the issue in selection, or is the issue in a build failure?
Are you saying for some reason all module selection options are missing, and it isn’t a particular option?
Possibly. Do not know, but would be a bit surprised if that was the case.
Selection.
When one runs make menuconfig it presents an ncurses UI and for each possible item to be built it presents the item in the following manner - we will calll the item FooDev for expository purposes, along with some other random imagined things just to make the snippet a bit more realistic.
CharThing
FooDev
NullMaster9000
As seen above, the CharThing, FooDev and NullMaster9000 have a space between the square brackets. This means that they will not be built either as a module or as a part of the kernel.
if i used the arrow keys in the Ncurses UI to navigate to:
FooDev
and then tapped the space bar in a typical kernel build the ’ ’ between the 2 square brackets would be replaced with an ‘M’:
[M] FooDev
As a result, FooDev will be built as a module and will show up in it’s build directory as FooDev.ko
If I hit the spacebar again then in a typical kernel build the ‘M’ between the 2 square brackets would be replaced with an ‘*’:
[*] FooDev
As a result, FooDev will be linked statically into the kernel and FooDev.ko will not be created.
If I hit the spacebar again then in a typical kernel build the ‘*’ between the 2 square brackets would be replaced with an ’ ':
FooDev
So now we are back the original state where FooDev will not be built.
On Xavier the module section state ‘M’ NEVER OCCURS. It only toggles between ’ ’ and ‘*’.
This isn’t a bug, and it isn’t related to the Xavier itself (unless someone at NVIDIA wrote the feature specifically for Xavier…but I’m guessing the feature is part of the mainline kernel and isn’t custom to Xavier or Tegra).
This implies that the code can only be an integral feature (this is how the Kconfig arranged it). Even if you forced it to be a module it wouldn’t work. To emphasize, the original author would have to have written extra code for this to be a module…that code apparently doesn’t exist on this feature. Sometimes it is just because the author didn’t care to write the code, but this is actually quite rare…by far the most common reason for this is that the code is invasive in such a way that it doesn’t make sense to make the code removable.
I don’t know anything about your specific feature, but to actually know why this is the case you’d probably have to research the change notes and perhaps even the Linux kernel mailing list.