I'm trying to recompile my Linux Kernel 3.18 with DRM_KMS_CMA_HELPER enabled, but editing the .config file is not working.
I have the dependencies enabled, but it still shows and not enabled.
Is there a way i can do this without editing the Kconfig file? Do i need to enable any special module for it to work?
Some symbols are not allowed to be explicitly selected by the user, but instead they are meant to be selected by other symbols.
You can identify such symbols because they don't have a "prompt" next to the symbol type (bool, tristate). This is the case of CONFIG_KMS_DMA_HELPER:
config DRM_KMS_CMA_HELPER
bool
select DRM_GEM_CMA_HELPER
select DRM_KMS_FB_HELPER
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
help
Choose this if you need the KMS CMA helper functions
In contrast, here's a symbol with a "prompt" text:
config KERNEL_GZIP
bool "Gzip"
depends on HAVE_KERNEL_GZIP
help
The old and tried gzip compression. It provides a good balance
between compression ratio and decompression speed.
In other words, it's not possible to explicitly enable CONFIG_DRM_KMS_CMA_HELPER. It's meant to be selected by other symbols (DRM drivers such as rcar-du, shmobile, tilcdc, and others).
Thus, if you are writing a driver that needs the functions provided when such option is enabled, you can simply select the option as the mentioned DRM drivers do.
Related
To compile Linux kernel, I created a default .config file using make defconfig. Since I didn't want to browse thousands of options through a menu-driven interface (make menuconfig), I set CONFIG_KALLSYMS=n manually, and then triggered the build (make -j8). I noticed the build system overwrote my changes and set CONFIG_KALLSYMS=y again. I suspect there might be other options present in the configuration which rely on CONFIG_KALLSYMS. How can I create a consistent .config file without using any menu-driven interface?
It might be burdensome to browse thousands of options through a menu-driven interface (make menuconfig). When you only want to change a couple of options and don't remember where they are in the menu hierarchy, you can use search to find any specific option. Just press / (slash) and type the full or partial name of the option. The result of the search will show where the options are located in the menu hierarchy, and what are the dependencies. Save and exit after you are done with the changes, and you should have a consistent .config file.
After you create a .config using make defconfig, to change just a few config options after that "make menuconfig" is the best way to do this. It also tells you about the dependencies and doesn't allow you to make a change unless the dependencies are met.
I want to disable certain keys while creating image in yocto. I know in users pace we can achieve this with xmodmap utility but I want to achieve this kernel itself.
I checked drivers/try/vt/defkeymap.map file and modified as per my requirement but loadkeys not able to generate defkeymap.c file. It throws this error:
/bin/sh: 1: loadkeys: not found.
Am I going in the right direction? Or is there any other option to change default keycode map?
The raw keyboard data is scan codes that the keyboard driver converts into key codes cf https://unix.stackexchange.com/questions/319787/how-does-the-linux-kernel-handle-keyboards-inputs-outputs. A way to generate a custom keyoard layout for console is in https://wiki.archlinux.org/index.php/Linux_console/Keyboard_configuration#Creating_a_custom_keymap, so you do not edit a driver file, loadkeys requires changes in specific directory / file :
As a side note, it is worth noting that such a personal keymap is
useful also to redefine the behaviour of keys already treated by the
default keymap: when loaded with loadkeys, the directives in the
default keymap will be replaced when they conflict with the new
directives and conserved otherwise. This way, only changes to the
keymap must be specified in the personal keymap.
source : https://wiki.archlinux.org/index.php/Linux_console/Keyboard_configuration#Creating_a_custom_keymap
If you want to do this on kernel module level you have to rewrite or patch the entire keyboard module.
In https://unix.stackexchange.com/questions/319787/how-does-the-linux-kernel-handle-keyboards-inputs-outputs is many essential information ( links to source code, ... ) for all levels, including solving this issue on kernel module level ( writing / patching kernel module )
I observe that .convert files look similar to .override files. Override files end with .gschema.override suffix. I believe that gsettings-data-convert or any other utility creates the .override files. I am looking forward to any link that can explain the complete conversion process.
GSettings vendor overrides and .convert files for gsettings-data-convert are very different.
Vendor overrides are used to allow OS vendors (for example, a particular Linux distribution) to override the default values of settings shipped by an application or part of the desktop, without having to patch the code for that application. They are used quite commonly.
.convert files were historically used to map GConf keys to GSettings schema keys, so that data stored in GConf could be migrated to GSettings/dconf without manual migration code having to be written. Now that GConf has been deprecated since 2011 and unmaintained since 2013, the need for .convert files has dropped off. There should not really be any applications left using GConf (if they are, they need to migrate away from it ASAP). Hence you wouldn’t normally ever need to use a .convert file any more.
I was going through a Linux KERNEL configuration file wherein function_trace is enabled but debugfs is disabled. If i load this kernel onto the target is there any way, I can make use of the function_tracer ? if debugfs is disabled is it that the function tracer is not enabled by default ?
Technically it's not possible to select function_trace without debugfs enabled. As per tracing configuration file (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel/trace/Kconfig#n140), it suggest that - if you select FUNCTION_TRACER, it'll automatically select GENERIC_TRACER and when GENERIC_TRACER is selected this will automatically select TRACING (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel/trace/Kconfig#n112) and when TRACING is selected it'll select DEBUG_FS (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel/trace/Kconfig#n101).
So, it's a linked list of selection procedure and you do not need to select each option every time. Until unless you've modified config file by hand and it's not recommended.
Is it possible to DISABLE source code view in backtrace, to display only line numbers and file names?
I mean do NOT include these informations to application, because you can also read from the application file.
I don't want anyone to see my source code.
If it's impossible in GDB, is there any other debugger with such feature?
GDB can only show your source code if it can find your original source files. If people can see your source in the backtrace, then presumably they can also see your entire source base.
Therefore, I suspect you mean that you do not want the compiler to include any of your sources in the application binaries?
In fact, the application binaries only contain the source filenames, line numbers, symbol names (such as function and variable names), and some type information. If you use -g3 then they might also include preprocessor macros, but most people just use -g.
The easiest way to exclude the 'source' information is to not ship binaries with debug information. You can either build it without using -g in the first place, or you can use strip to remove it after the fact.
Not building with debug info will remove all symbol names that are not absolutely necessary (including static functions, and all local variable names), but it will not remove the symbol names for externally visible functions: the linker needs to see those. strip can remove some of those also, I think, although I've never tried. Beware that libraries must have symbol names for externally visible function.
Removing debug info will also remove line-number information, and source file names, so this still isn't quite what you want.
I'd suggest a) refactoring your source code so that isn't embarrassing and/or give away any clues, and b) don't ship with debug info.