On Thu, Nov 26, 2020 at 04:58:17PM -0600, rhubarbpieguy--- via blfs-support
wrote:
Dear Mr Pie Guy (since I have no other way to call you), I'm afread
such a long detailed post gets a long detailed reply. for some of
the minor points I now think I agree with you, but for much of it I
think the situation is more complex that what you are initially
seeing (and that thought has developed during this reply, so what I
say later is built upon, and developed from, my initial reply on
autofs. Please read the whole reply before replying to any of it,
otherwise I will have wasted 2½ hours.
>
> autofs
>
> File systems --->
> <*/M> Kernel automounter version 4 support (also supports v3)
> [CONFIG_AUTOFS4_FS]
>
> I believe Kernel automounter support has no options. Should the above
> lines be deleted?
>
As of 5.9.8 (I forget when it changed) CONFIG_AUTOFS_FS is the new
option. In my case, on a fresh tarball it is selected by the old
AUTOFS4_FS and it appears that it cannot be disabled or modularized.
In the .config I'm using for this machine (updated for 5.9.1)
# CONFIG_AUTOFS4_FS is not set
CONFIG_AUTOFS_FS=y
Looking back at the config for this machine, I have not always saved
a new config for a new kernel version in my git tree. In this case,
somewhere between 4.20.1 and 5.3.4 CONFIG_AUTOFS got enabled (unsure
now if that was automatic or by my choice). Looking at my other
machines, AUTOFS is enabled on all of them except for my desktop
haswell (again, updated for 5.9.1) which has
CONFIG_AUTOFS4_FS=m
CONFIG_AUTOFS_FS=m
So it looks as if AUTOFS (whether that or AUTOFS4 is the correct
item to sepcify, I'm unsure - the 4 variant was supposed to be
transitory, or for help in converting old configs - I think) can be
a module. Not sure if it can be turned off nowadays (that would be
nice, there is so much enabled in modern kernels which I don't
need).
> File systems --->
> [*] Network File Systems ---> [CONFIG_NETWORK_FILESYSTEMS]
> <*/M> NFS client support
> [CONFIG_NFS_FS]
> <*/M> CIFS support (advanced network filesystem, SMBFS successor)
> [CONFIG_CIFS]
>
> Should CIFS support (advanced network filesystem, SMBFS successor) be
> SMB3 and CIFS support (advanced network filesystem)?
I guess so.
> --------------------------------------------------------------------------------------------------------------
>
>
> BlueZ
>
> [*] Networking support ---> [CONFIG_NET]
> </M> Bluetooth subsystem support ---> [CONFIG_BT]
>
> Is </M> correct? Should it be <M>? <*/M>?
>
No idea. ISTR you have mentioned using bluetooth for input devices
? If so, can you build it in, and if so does it work better as
built-in (e.g. easier pairing) or as a module (e.g. sometime need to
rmmod and reload if it loses the connection) ?
> <*/M> RF switch subsystem support ---> [CONFIG_RFKILL]
>
> Should RF switch subsystem support ---> be RF switch subsystem support
> ----?
I don't understand, the words after 'Should' and 'be' look identical
to me, maybe you didn't type what you intended ?
>
> [*] Networking support ---> [CONFIG_NET]
> -*- Cryptographic API ---> [CONFIG_CRYPTO]
> </M> User-space interface for hash algorithms
> [CONFIG_CRYPTO_USER_API_HASH]
> </M> User-space interface for symmetric key cipher algorithms
> [CONFIG_CRYPTO_USER_API_SKCIPHER]
>
> I believe Cryptographic API has no options. Could [CONFIG_CRYPTO] be
> deleted as in cryptsetup?
>
On 5.9.8 Cryptographic API has loads of options.
Near the bottom are
< > User-space interface for hash algorithms (NEW)
< > User-space interface for symmetric key cipher algorithms (NEW)
> As with the above, should the hash algorithms and key cipher lines be
> <M>? <*/M>?
> --------------------------------------------------------------------------------------------------------------
>
>
> lm-sensors
>
> [*] Enable loadable module support ---> [CONFIG_MODULES]
>
> Bus options (PCI etc.) --->
> [*] PCI support [CONFIG_PCI]
>
> Should Enable loadable module support and Bus options be reversed to
> follow the order displayed with menuconfig?
No idea. Where is MODULES found now ? I assume it is somewhere in
General setup, but I can't see it and it seems to be enabled by
default. According to the help (which might be out of date), PCI is
somewhere under Device Drivers.
>
> Device Drivers --->
> I2C support --->
> <*/M> I2C device interface [CONFIG_I2C_CHARDEV]
> I2C Hardware Bus support --->
> <M> (configure all of them as modules)
> <*/M> Hardware Monitoring support ---> [CONFIG_HWMON]
>
> I believe Hardware Monitoring support has no options. Should it be -*-
> Hardware Monitoring Support? If so, could [CONFIG_HWMON] be deleted?
Depends on your hardware for whether or not it gets selected:
(From the help on a fresh 5.9.8 tree)
Symbol: HWMON [=y]
│ Type : tristate
│ Defined at drivers/hwmon/Kconfig:6
│ Prompt: Hardware Monitoring support
│ Depends on: HAS_IOMEM [=y]
│ Location:
│ (1) -> Device Drivers
│ Selected by [y]:
│ - EEEPC_LAPTOP [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && ACPI [=y]
&& INPUT [=y] &
(probably scrolled right off my 100-character-wide term)
│ Selected by [n]:
│ - I8K [=n]
│ - HABANA_AI [=n] && PCI [=y] && HAS_IOMEM [=y]
│ - DRM_RADEON [=n] && HAS_IOMEM [=y] && DRM [=y] && PCI [=y] && MMU [=y]
│ - DRM_AMDGPU [=n] && HAS_IOMEM [=y] && DRM [=y] && PCI [=y] && MMU [=y]
│ - THINKPAD_ACPI [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && ACPI
[=y] && ACPI_BATTER
│ - CPU_HWMON [=n] && MIPS && MIPS_PLATFORM_DEVICES [=n] && MACH_LOONGSON64
│ - NTB_IDT [=n] && NTB [=n] && PCI [=y]
│ Implied by [n]:
│ - VIDEO_I2C [=n] && MEDIA_SUPPORT [=n] && VIDEO_V4L2 [=n] && I2C [=y]
│
But there are lots (more than 100, I would guess) of hwmon drivers
which could be built so for me it has a lot of options.
> --------------------------------------------------------------------------------------------------------------
>
>
> UPower
>
> General Setup --->
> [*] Namespaces support ---> [CONFIG_NAMESPACES]
>
> I believe Namespaces support has no options. Should it be -*- Namespaces
> support? If so, could [CONFIG_NAMESPACES] be deleted?
Symbol: NAMESPACES [=y]
│ Type : bool
│ Defined at init/Kconfig:1123
│ Prompt: Namespaces support
│ Depends on: MULTIUSER [=y]
│ Visible if: MULTIUSER [=y] && EXPERT [=n]
│ Location:
│ (1) -> General setup
So it is only playable in expert configs (as in "Do you feel
lucky?"). But '[*]' is in practice the same as '-*-' isn't it ?
> --------------------------------------------------------------------------------------------------------------
>
>
> Cheese
>
> Device Drivers --->
> Multimedia support --->
> <*> Cameras/video grabbers support [CONFIG_MEDIA_CAMERA_SUPPORT]
> <*> Media USB Adapters ---> [CONFIG_MEDIA_USB_SUPPORT]
>
> Should the above be:
>
> Device Drivers --->
> <*> Multimedia support --->
> Media device types --->
> <*> Cameras and video grabbers [CONFIG_MEDIA_CAMERA_SUPPORT]
> Media drivers --->
> <*> Media USB Adapters ---> [CONFIG_MEDIA_USB_SUPPORT]
>
> The documentation implies nothing is to be built as a module.
I've no interest in cheese, but again I think there are a number of
possible things which can be built as modules, or compiled in, if
you enable the above options (or if something else in your config
enables them).
> --------------------------------------------------------------------------------------------------------------
>
>
> alsa-lib
>
> Device Drivers --->
> <*/m> Sound card support ---> [CONFIG_SOUND]
> <*/m> Advanced Linux Sound Architecture ---> [CONFIG_SND]
>
> Should the <*/m>'s above be <*/M> for consistency with the documentation?
On reading all of your post, I suppose so if we are using capital M
elsewhere.
> --------------------------------------------------------------------------------------------------------------
>
>
> cryptsetup
>
> Cryptographic API --->
> <*/M> XTS support [CONFIG_CRYPTO_XTS]
> <*/M> SHA224 and SHA256 digest algorithm [CONFIG_CRYPTO_SHA256]
>
> Should Cryptographic API ---> be -*- Cryptographic API --->?
>
> I believe SHA224 and SHA256 digest algorithm has no options Should the
> line be deleted?
Again, it is selected by other things, no idea if it can be a module
(crypto has a horrible tendency to select new things in each kernel
release, for me this is all 'Y').
> --------------------------------------------------------------------------------------------------------------
>
>
> dosfstools
>
> File systems --->
> <DOS/FAT/NT Filesystems --->
>
> Should <DOS/FAT/NT Filesystems ---> be DOS/FAT/EXFAT/NT Filesystems --->?
Yes, I think so (but obviously only the FAT and VFAT options are
elevant to dosfstools).
> --------------------------------------------------------------------------------------------------------------
>
>
> About Firmware
>
> General Setup --->
> [y] Initial RAM filesystem and RAM disk (initramfs/initrd) support
> [CONFIG_BLK_DEV_INITRD]
> Processor type and features --->
> [y] CPU microcode loading support [CONFIG_MICROCODE]
> [y] AMD microcode loading support [CONFIG_MICROCODE_AMD]
>
> Should the [y]'s above be <*> for consistency with the documentation?
I suppose so - 'y' to enable will show as '[*]'.
> --------------------------------------------------------------------------------------------------------------
>
>
> iptables
>
> [*] Networking support --->
> [CONFIG_NET]
> Networking Options --->
> [*] Network packet filtering framework (Netfilter) --->
> [CONFIG_NETFILTER]
> [*] Advanced netfilter configuration
> [CONFIG_NETFILTER_ADVANCED]
> Core Netfilter Configuration --->
> <*/M> Netfilter connection tracking support
> [CONFIG_NF_CONNTRACK]
> <*/M> Netfilter Xtables support (required for ip_tables)
> [CONFIG_NETFILTER_XTABLES]
>
> I believe Netfilter Xtables support (required for ip_tables) has no
> options. Should the line be deleted?
No idea, netfilter seems to be in perpetual change.
> --------------------------------------------------------------------------------------------------------------
>
>
> LVM2
>
> Kernel hacking --->
> [*] Magic SysRq key [CONFIG_MAGIC_SYSRQ]
>
> Should the above be:
>
> Kernel hacking --->
> Generic Kernel Debugging Instruments --->
> [*] Magic SysRq key [CONFIG_MAGIC_SYSRQ]
Yes, I think so.
> --------------------------------------------------------------------------------------------------------------
>
>
> qemu
>
> [*] Virtualization: ---> [CONFIG_VIRTUALIZATION]
> <*/M> Kernel-based Virtual Machine (KVM) support [CONFIG_KVM]
> <*/M> KVM for Intel processors support [CONFIG_KVM_INTEL]
>
> Should KVM for Intel processors support be KVM for Intel (and compatible)
> processors support?
Apparently.
> --------------------------------------------------------------------------------------------------------------
>
>
> Cups
>
> Device Drivers --->
> <*/M> Parallel port support ---> [CONFIG_PARPORT]
> <*/M> PC-style hardware [CONFIG_PARPORT_PC]
> Character devices --->
> <*/M> Parallel printer support [CONFIG_PRINTER]
>
> I see no CONFIG_PRINTER in .config. Can the Character devices and
> Parallel printer lines be deleted? I do see CONFIG_USB_PRINTER.
The kernel help suggests it is in Device Drivers / Character
Devices. It shows up if you enable (or modularize) PARPORT_PC
< > Parallel printer support (NEW)
> --------------------------------------------------------------------------------------------------------------
>
>
> libevdev
>
> Device Drivers --->
> Input device support --->
> <*> Generic input layer (needed for...) [CONFIG_INPUT]
>
> Should Generic input layer (needed for...) be Generic input layer (needed
> for keyboard, mouse, ...)?
That sounds as if someone didn't want to write a long line there and
then have to move CONFIG names for the following items over to
match. When explain sed commands we often use ellipsis (or, strictly
3 dots since the markup requires 8859-1 so not a real ellipsis: … )
and this is the same. I see no particular reason to add 'keyboard,
mouse,' when the full list of possible items is not spelled out by
the kernel). But if someone else wants to add it, I don't have deep
feelings.
> --------------------------------------------------------------------------------------------------------------
>
>
> Xorg Wacom Driver
>
> Device Drivers --->
> HID support --->
> <*/M> HID bus support [CONFIG_HID]
>
> I believe HID bus support has no options. Should it be -*- HID bus
> support? If so, could [CONFIG_HID] be deleted?
For me, the bus support is selected by three other things (USB_HID,
USB, INPUT). Someone using an initrd could maybe make all of those
into modules (/me shudders) and therefore make bus support a module.
> --------------------------------------------------------------------------------------------------------------
>
>
> Xorg AMDGPU Driver
>
> Device Drivers --->
> Graphics support --->
> <*> Direct Rendering Manager (XFree86 ... support) ---> [CONFIG_DRM]
> <*/M> AMD GPU [CONFIG_DRM_AMDGPU]
> [ /*] Enable amdgpu support for SI parts [CONFIG_DRM_AMDGPU_SI]
> [ /*] Enable amdgpu support for CIK parts [CONFIG_DRM_AMDGPU_CIK]
>
> Should the [ /*]'s above be [*]?
>
Yes, these are either on or off (so if amdgpu is a module, either it
supports SI or it doesn't, and similarly either it supports CIK or
it doesn't.)
Overall, navigating menuconfig has become a lot worse in the last
few years, partly because there are an order of magnitude more
options for new things (many of which we will never experience on
x86, but some of which can nevertheless be enabled), and things tend
not to be in alphabetical order, but also because things sometimes
move and also because (as with PRINTER above) things will not show
up if their dpeendencies are not met.
For some of the above, I'm not prepared to touch them. For others,
I think you need to examine the help from menuconfig to try to prove
that the options in the book can be made to appear.
I've added the above where I'm in agreement to my ToDo-if-I-remember
list. (Redoing dvisvgm, and adding some clarification elsewhere are
in front of it, maybe those will be done this weekend.)
Some further thoughts for you to consider:
1. A single long file, particularly when it has those very long
'----' lines you have used, is hard to read. A series of posts for
different items (and perhaps wait for feedback) will be easier to
handle.
2. linux-5.10 is expected to be released around the end of the year.
I expect that each new kernel release will change some of the
detail. If we can get it to match the current kernel, someone then
need to re-examine it after a new kernel version hits LFS (probably
when .1 is released, but .0 is as good a time as any to start
reviewing any changes (and to see if the kernel works!). Are you
interested ?
3. For proving what can indeed by made into modules, perhaps it is
easiest to begin with 'make allmodconfig' and then follow with 'make
menuconfig' and search for the items to see what resulted. On the
items where I'm not prepared to agree with you at this point, doing
that and documenting it would help clarify what can and cannot be a
module. Up to you.
ĸen
--
Internal error in fortune program:
fnum=2987 n=45 flag=1 goose_level=-232323
Please write down these values and notify fortune program admin.
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
