Why isn't my Kconfig entry appearing in menuconfig? - linux-kernel

I have the following entry in drivers/media/video/Kconfig:
config VIDEO_OMAP3
tristate "OMAP 3 Camera support"
select VIDEOBUF_GEN
select VIDEOBUF_DMA_SG
select OMAP_IOMMU
depends on VIDEO_V4L2 && ARCH_OMAP34XX
---help---
Driver for an OMAP 3 camera controller.
When I search for VIDEO_OMAP3 in menuconfig I get:
Symbol: VIDEO_OMAP3 [=n]
Prompt: OMAP 3 Camera support
Defined at drivers/media/video/Kconfig:836
Depends on: MEDIA_SUPPORT [=y] && VIDEO_CAPTURE_DRIVERS [=y] && VIDEO_V4L2 [=y] && ARCH_OMAP34XX [=ARCH_OMAP34XX]
Location:
-> Device Drivers
-> Multimedia support (MEDIA_SUPPORT [=y])
-> Video capture adapters (VIDEO_CAPTURE_DRIVERS [=y])
But there is no menuconfig option. I can manually force the object to build by modifying the makefile but I want to ensure that this isn't part of a larger problem.

More specifically, symbols that aren't defined are always "n" in a tristate sense. The reason you get the "[=ARCH_OMAP34XX]" is that they also happen to get their name as their value.
As a side note, this quirk is the reason why
if FOO = BAR
...
endif
works the same as
if FOO = "BAR"
...
endif
provided BAR is undefined. In the former case, BAR gets the value "BAR".
(I'm the author of Kconfiglib, a Python library for working with Kconfig-based configuration systems.)

ARCH_OMAP34XX is not defined it seems. If it were, you would see ARCH_OMAP34XX [=y] or [=n]. But not [=ARCH_OMAP34XX].

Related

How does "bitbake virtual/kernel" work if kernel recipes don't have PROVIDES variable set to virtual/kernel?

I'm trying to understand a few pieces associated with using bitbake to compile the linux image and generating a boot image that would be used to flash onto the processor.
How come bitbake virtual/kernel really works? Read through section 2.3 and it says recipes use PROVIDES parameter to add an extra provider, which indicates a recipe could be called in multiple ways (by its name, and by whatever PROVIDES is set to). But the kernel recipes (../poky/meta-bsp/recipes-kernel) I checked didn't have PROVIDES parameter let alone it being set to virtual/kernel.
Upon running bitbake virtual/kernel, how come a boot.img is being generated when it should only just be generating a linux binary i.e vmlinux for instance?
In one of the kernel .inc files, I see:
DEPENDS += " mkbootimg-native openssl-native kern-tools-native"
...
FILESPATH =+ "${WORKSPACE}:"
SRC_URI = "file://kernel \
${#bb.utils.contains('DISTRO_FEATURES', 'systemd', 'file://systemd.cfg', '', d)} \
${#bb.utils.contains('DISTRO_FEATURES', 'virtualization', 'file://virtualization.cfg', '', d)} \
${#bb.utils.contains('DISTRO_FEATURES', 'nand-squashfs', 'file://squashfs.cfg', '', d)} \
mkbootimg-native I reckon refers to the boot image recipe that the kernel recipe depends on, though shouldn't it be the other way around since the boot image should contain the kernel image itself?
lastly, is there a way to put debug prints in different recipe files to see if it's being invoked? I tried echo...to no avail
The recipes you checked probably had PROVIDES. Most if not all kernel recipes inherit kernel class (directly or via some other classes, such as kernel-yocto). The kernel.bbclass actually specifies PROVIDES for you, c.f. http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel.bbclass#n8).
boot.img does not seem to be created by default for any machine. After a quick glance at the code, it seems that this is created by wic for images inheriting the image-live bbclass or by adding live to IMAGE_FSTYPES, c.f. http://docs.yoctoproject.org/ref-manual/classes.html#image-live-bbclass.
From a simple git grep in the poky git repo, it seems only bootimg-efi.py is actually doing something with a boot.img which is called by wic when the -b or --bootimg-dir argument is passed, which is enforced when using wic. So probably the boot.img artifact is created only for EFI machines and images.
If you use echo or printf or similar shell functions (or print in Python tasks) in your tasks, you can only see them in ${WORKDIR}/temp/log.do_<task> of your recipe. Otherwise, you can use bbplain, bbnote, bbdebug, bbwarn, bberror or bbfatal. This will print to both the logs and the console (depending on your log level which is configurable with -D (the more Ds, the higher the log level)).

Autoconf: check struct member type

I am new to autoconf so I would ask you how could I check if a struct member is declared with a particular type.
For example I should check if struct posix_acl.a_refcount is declared as refcount_t and not atomic_t.
I know AC functions as ac_fn_c_check_decl and ac_fn_c_check_member, but none that accomplish this task.
Thank you!
Disclaimer: As there are no other answers at the time this answer is being written, this represents my best attempt to provide a solution, but you may need to adjust things to make it work for you. Caveat emptor.
You would need to use the AC_COMPILE_IFELSE macro with code that uses atomic_t, and if the compilation succeeds, then you're using atomic_t. As future-proofing, you might also add a test for refcount_t if the atomic_t test fails.
Example:
# _POSIX_ACL_REFCOUNT_T(type-to-check)
# ------------------------------------
# Checks whether the Linux kernel's `struct posix_acl'
# type uses `type-to-check' for its `a_refcount' member.
# Sets the shell variable `posix_acl_refcount_type' to
# `type-to-check' if that type is used, else the shell
# variable remains unset.
m4_define([_POSIX_ACL_REFCOUNT_T], [
AC_REQUIRE([AC_PROG_CC])
AC_MSG_CHECKING([whether struct posix_acl uses $1 for refcounts])
AC_COMPILE_IFELSE(
[AC_LANG_SOURCE(
[#include <uapi/../linux/posix_acl.h>
struct posix_acl acl;
$1 v = acl.a_refcount;]
)],
[AC_MSG_RESULT([yes])
AS_VAR_SET([posix_acl_refcount_type], [$1])],
[AC_MSG_RESULT([no])
)
])
_POSIX_ACL_REFCOUNT_T([atomic_t])
# If posix_acl_refcount_type isn't set, see if it works with refcount_t.
AS_VAR_SET_IF([posix_acl_refcount_type],
[],
[_POSIX_ACL_REFCOUNT_T([refcount_t])]
)
dnl
dnl Add future AS_VAR_SET_IF tests as shown above for the refcount type
dnl before the AS_VAR_SET_IF below, if necessary.
dnl
AS_VAR_SET_IF([posix_acl_refcount_type],
[],
[AC_MSG_FAILURE([struct posix_acl uses an unrecognized type for refcounts])]
)
AC_DEFINE([POSIX_ACL_REFCOUNT_T], [$posix_acl_refcount_type],
[The type used for the a_refcount member of the Linux kernel's posix_acl struct.])
The tests assume that you already have a variable containing the kernel source directory, and the kernel source's include directory is specified in CPPFLAGS or CFLAGS prior to attempting the tests. You can add more tests at the position indicated, and if the resulting posix_acl_refcount_type shell variable is still not defined after all those tests, then the final AS_VAR_SET_IF invocation will invoke AC_MSG_FAILURE to stop configure with the specified error message.
Note that I used <uapi/../linux/posix_acl.h> to specifically target the kernel's linux/posix_acl.h header rather than the userspace API uapi/linux/posix_acl.h header installed in a system's include directory with the uapi/ stripped off, which may result in the compile tests above failing due to the missing struct posix_acl in the userspace API. This may not work the way I'd expect and may need modification.

Grub throws "can't find command `['." when adding conditional to grub.cfg

It was my understanding that grub supports a small subset of bash. Their documentation doesn't go into super detail, other than it "supports conditionals", etc.
I am trying to run a simple if.
grub> if [ "${myvar}" = "fred" ]; then
> echo "test"
> fi
error: can't find command `['.
Anybody have an idea? I am using grub2-efi 2.00.
You are missing a grub2 module in order to run if tests.
I'm running Gentoo on a PowerPC system (PPC64 G5 machine) and doing a default grub-mkconfig then booting from it gives me the error in your question.
Since bash has that syntax support, I figured it was simply a grub module that needed to be added (I had been doing work with grub modules recently).
tl;dr: You need to load the appropriate grub module and then the error goes away.
The first step is to find out what modules you have. For me, it's whatever is available in my /boot/grub/powerpc-ieee1275/ folder.
There's also modules in /usr/lib/grub/powerpc-ieee1275/.
I wrote up a list of modules I thought I needed:
normal
eval
read
test
test_blockarg
trig
true
I then added them to my /etc/default/grub file:
GRUB_PRELOAD_MODULES="normal eval read test test_blockarg trig true"
I did not find an entry for GRUB_PRELOAD_MODULES in the config file, so I had to do some searching to find out how. I want these modules to be added every time I generate the grub config file, which means putting them in the 00_header portion of grub.
Then I recreated the configuration file:
grub-mkconfig -o /boot/grub/grub.cfg
The modules were in the header and things worked perfectly on reboot.
If I had to guess: you probably only need the test module to enable if statements.

dyld_insert_libraries ignored when calling application through bash

For my application, I am using DYLD_INSERT_LIBRARIES to switch libraries. I am running Mac OS X, El Capitan.
If I set these environment variables in my shell:
export PYTHONHOME=${HOME}/anaconda
export DYLD_INSERT_LIBRARIES=${HOME}/anaconda/lib/libpython2.7.dylib:${HOME}/anaconda/lib/libmkl_rt.dylib
If I launch my application directly, it works properly. However, if I call it through a bash script I have written, the DYLD_INSERT_LIBRARIES is ignored.
If I add the same 2 lines to my bash script, my application works again.
It looks like DYLD_INSERT_LIBRARIES is being unset when the bash script is called, as proven by this test script.
#!/bin/bash
set -e
echo ${DYLD_INSERT_LIBRARIES}
Is there any way to let the bash script inherit and pass down DYLD_INSERT_LIBRARIES?
This is a security feature of recent macOS versions.
The system bash executable has been marked as "restricted", disabling the DYLD_* features. To work around this, you can make a copy of bash and use that instead.
By looking for the following details in the implementations of dyld, I see that this restriction goes back at least to 10.6.
In the macOS 10.13 dyld implementation this logic is in pruneEnvironmentVariables, with the comment:
// For security, setuid programs ignore DYLD_* environment variables.
// Additionally, the DYLD_* enviroment variables are removed
// from the environment, so that any child processes don't see them.
However the actual logic to set the restriction is in configureProcessRestrictions:
// any processes with setuid or setgid bit set or with __RESTRICT segment is restricted
if ( issetugid() || hasRestrictedSegment(mainExecutableMH) ) {
gLinkContext.processIsRestricted = true;
}
...
if ( csops(0, CS_OPS_STATUS, &flags, sizeof(flags)) != -1 ) {
// On OS X CS_RESTRICT means the program was signed with entitlements
if ( ((flags & CS_RESTRICT) == CS_RESTRICT) && usingSIP ) {
gLinkContext.processIsRestricted = true;
}
// Library Validation loosens searching but requires everything to be code signed
if ( flags & CS_REQUIRE_LV ) {
gLinkContext.processIsRestricted = false;
...
As you can see, it depends on, issetugid, hasRestrictedSegment, and the CS_RESTRICT / SIP entitlements. You might be able to test for restricted status directly, or you could probably construct a function to test for these conditions yourself based on this information.

buildroot - how to change kernel version string

I work on SAM9G25 EK board with buildroot and Armstrong linux (Linux4sam).
My script is creating linux version "2.6.39+" and this "+" is confusing (/lib/modules folder etc.). I want to remove it. I found only two files .uImage.cmd, and kernel.release that contains this string, but both are generated.
Where is this string created ?
You have a .config? Look in there for the value assigned to CONFIG_LOCALVERSION.
To have no local version specifed in the kernel's release, either remove CONFIG_LOCALVERSION or comment it out by starting the line containing it by a #.
The default shall be:
#CONFIG_LOCALVERSION is not set
In this case the main reason was :
scripts/setlocalversion line >170:
# append a plus sign if the repository is not in a clean
# annotated or signed tagged state (as git describe only
# looks at signed or annotated tags - git tag -a/-s) and
# LOCALVERSION= is not specified
if test "${LOCALVERSION+set}" != "set"; then
scm=$(scm_version --short)
res="$res${scm:++}"
fi
I commented this part out.

Resources