kernel config options request

bartgymnast · 08-14-2013, 04:25 AM

I would like to request the following options in the slackware kernel

CONFIG_UEVENT_HELPER_PATH=""
CONFIG_FW_LOADER_USER_HELPER=n (should not be set)
CONFIG_FHANDLE=y
CONFIG_IPV6=y
CONFIG_AUTOFS4_FS=y
CONFIG_SCHEDSTATS=y

Explanation of the 3 top options are below:

CONFIG_UEVENT_HELPER_PATH:
Path to uevent helper program forked by the kernel for every uevent. Before the switch to the netlink-based uevent source, this was used to hook hotplug scripts into kernel device events. It usually pointed to a shell script at /sbin/hotplug. This should not be used today, because usual systems create many events at bootup or device discovery in a very short time frame. One forked process per event can create so many processes that it creates a high system load, or on smaller systems it is known to create out-of-memory situations during bootup.

To disable user space helper program execution at early boot time specify an empty string here. This setting can be altered via /proc/sys/kernel/hotplug or via /sys/kernel/uevent_helper later at runtime.

CONFIG_FW_LOADER_USER_HELPER:
On recent systems, if the kernel configures
CONFIG_FW_LOADER_USER_HELPER=y and a firmware is not found by the kernel, the kernel will issue a request which is ignored by userspace and will block in that for 60 seconds.

Udev is no longer in the game of firmware loading, not even as a fallback, it will just completely ignore all kernel firmware class events.

The source code in udev to handle firmware requests is disabled by default, currently still kept around for old kernels without the in-kernel firmware loader, but it will be deleted in the near future.

* slackware ships udev with the following configure options: --with-firmware-path=/lib/firmware/updates:/lib/firmware
this makes the above options in kernel useless

CONFIG_FHANDLE:
If you say Y here, a user level program will be able to map file names to handle and then later use the handle for different file system operations. This is useful in implementing userspace file servers, which now track files using handles instead of names. The handle would remain the same even if file names get renamed. Enables open_by_handle_at(2) and name_to_handle_at(2) syscalls.

ReaperX7 · 08-14-2013, 08:46 PM

Didn't we ditch hotplug for udev to handle things like Firmware handling and such?

GazL · 08-15-2013, 03:35 AM

Poor Pat. No sooner does 3.10.6 hit current than Greg releases 3.10.7! Still, it gives him the opportunity to look at the above I suppose.

Is anything making use of the new fhandle features yet? Slackware doesn't even include the man pages for those syscalls.

I'm not sure I agree with you on including ipv6 (which I don't use) and autofs4 (which I do use). IMO they're still not commonly used and better as modules. And schedstats isn't that a debug option in the kernel hacking section?

gmgf · 08-15-2013, 03:57 AM

kernel-3.10.6 have serious bug on usb2 sd device, don't mount and umount this device correctly here, reboot crash when a sd device is connected

i have compiled a kernel-3.10.7, and it work correctly

volkerdi · 08-15-2013, 04:28 AM

Quote:

Originally Posted by GazL

Poor Pat. No sooner does 3.10.6 hit current than Greg releases 3.10.7! Still, it gives him the opportunity to look at the above I suppose.

The first three changes are in the 3.10.6 kernels that are up now.

Quote:

Is anything making use of the new fhandle features yet? Slackware doesn't even include the man pages for those syscalls.

I'll give you one guess what is using them.

Quote:

I'm not sure I agree with you on including ipv6 (which I don't use) and autofs4 (which I do use). IMO they're still not commonly used and better as modules. And schedstats isn't that a debug option in the kernel hacking section?

I agree with this assessment.

Darth Vader · 08-15-2013, 04:33 AM

Also I strongly suggest:

Code:

CONFIG_DRM_LOAD_EDID_FIRMWARE=y

This feature is provided as a workaround for broken monitor hardware, and give the possibility to EDID data to be loaded from the /lib/firmware directory or one of the provided built-in data sets.

In other words, it offer an simple workaround for the well known "my KMS wants only 1024x768".

And no, the xorg.conf workaround is not a better solution, because, there we can use it as kernel parameter, and give possibility to activate this feature at will. Also, in this way, you fix also the kms console resolution. Personally, I have an (mini-)computer which have configured five monitors in this way.

Later...
I just discovered that the latest kernel update, at 3.10.6, ship that option activated. Thanks, P.V.!

GazL · 08-15-2013, 05:20 AM

Quote:

Originally Posted by volkerdi

I'll give you one guess what is using them.

That which must not be named?

astrogeek · 08-15-2013, 05:45 PM

Quote:

Originally Posted by GazL View Post
Poor Pat. No sooner does 3.10.6 hit current than Greg releases 3.10.7! Still, it gives him the opportunity to look at the above I suppose.

But Pat rises to the challenge...

Code:

Thu Aug 15 21:23:13 UTC 2013
a/bash-4.2.045-i486-1.txz:  Upgraded.
a/kernel-generic-3.10.7-i486-1.txz:  Upgraded.
a/kernel-generic-smp-3.10.7_smp-i686-1.txz:  Upgraded.
a/kernel-huge-3.10.7-i486-1.txz:  Upgraded.
a/kernel-huge-smp-3.10.7_smp-i686-1.txz:  Upgraded.
a/kernel-modules-3.10.7-i486-1.txz:  Upgraded.
a/kernel-modules-smp-3.10.7_smp-i686-1.txz:  Upgraded.
d/kernel-headers-3.10.7_smp-x86-1.txz:  Upgraded.
k/kernel-source-3.10.7_smp-noarch-1.txz:  Upgraded.
extra/bash-completion/bash-completion-2.1-noarch-1.txz:  Upgraded.
extra/linux-3.10.7-nosmp-sdk/*:  Upgraded.
isolinux/initrd.img:  Rebuilt.
kernels/*:  Upgraded.
usb-and-pxe-installers/usbboot.img:  Rebuilt.

jon lee · 08-19-2013, 01:17 AM

Quote:

Originally Posted by GazL

That which must not be named?

I'm guessing kio_nfs.so -ltirpc?
http://nfsv4.bullopensource.org/doc/tirpc_rpcbind.php