Re: compile kernel
Here in my of my config file for and64. My goal is to remove all these devices. In 2 or 3 devices only keep this one, and this one. SEE: PCI network (wm0) ; MII / PHY (inphy0) ; IDE (keep pciide* AND ahcisata*) # $NetBSD: GENERIC,v 1.599.4.5 2023/11/03 08:56:36 martin Exp $ # # GENERIC machine description file # # This machine description file is used to generate the default NetBSD # kernel. The generic kernel does not include all options, subsystems # and device drivers, but should be useful for most applications. # # The machine description file can be customised for your specific # machine to reduce the kernel size and improve its performance. # # For further information on compiling NetBSD kernels, see the config(8) # man page. # # For further information on hardware support for this architecture, see # the intro(4) man page. For further information about kernel options # for this architecture, see the options(4) man page. For an explanation # of each device driver in this file see the section 4 man page for the # device. include "arch/amd64/conf/std.amd64" options INCLUDE_CONFIG_FILE# embed config file in kernel binary #ident"GENERIC-$Revision: 1.599.4.5 $" maxusers64# estimated number of users # delay between "rebooting ..." message and hardware reset, in milliseconds #options CPURESET_DELAY=2000 # This option allows you to force a serial console at the specified # I/O address. see console(4) for details. #options CONSDEVNAME="\"com\"",CONADDR=0x2f8,CONSPEED=57600 #you don't want the option below ON iff you are using the #serial console option of the new boot strap code. #options CONS_OVERRIDE# Always use above! independent of boot info # The following options override the memory sizes passed in from the boot # block. Use them *only* if the boot block is unable to determine the correct # values. Note that the BIOS may *correctly* report less than 640k of base # memory if the extended BIOS data area is located at the top of base memory # (as is the case on most recent systems). #options REALBASEMEM=639# size of base memory (in KB) #options REALEXTMEM=15360# size of extended memory (in KB) # The following options limit the overall size of physical memory # and/or the maximum address used by the system. # Contrary to REALBASEMEM and REALEXTMEM, they still use the BIOS memory map # and can deal with holes in the memory layout. #options PHYSMEM_MAX_SIZE=64# max size of physical memory (in MB) #options PHYSMEM_MAX_ADDR=2048# don't use memory above this (in MB) # Standard system options options INSECURE# disable kernel security levels - X needs this options RTC_OFFSET=0# hardware clock is this many mins. west of GMT options NTP# NTP phase/frequency locked loop options KTRACE# system call tracing via ktrace(1) options CPU_UCODE# cpu ucode loading support # Note: SysV IPC parameters could be changed dynamically, see sysctl(8). options SYSVMSG# System V-like message queues options SYSVSEM# System V-like semaphores options SYSVSHM# System V-like memory sharing options MODULAR# new style module(7) framework options MODULAR_DEFAULT_AUTOLOAD options USERCONF# userconf(4) support #options PIPE_SOCKETPAIR# smaller, but slower pipe(2) options SYSCTL_INCLUDE_DESCR# Include sysctl descriptions in kernel # CPU-related options options USER_LDT# User-settable LDT, used by Wine options SVS# Separate Virtual Space options PCPU_IDT# Per CPU IDTs # GCC Spectre variant 2 mitigation makeoptionsSPECTRE_V2_GCC_MITIGATION=1 options SPECTRE_V2_GCC_MITIGATION # CPU features acpicpu*at cpu?# ACPI CPU (including frequency scaling) coretemp*at cpu?# Intel on-die thermal sensor est0at cpu0# Intel Enhanced SpeedStep (non-ACPI) hyperv0 at cpu0# Microsoft Hyper-V #odcm0at cpu0# On-demand clock modulation powernow0at cpu0# AMD PowerNow! and Cool'n'Quiet (non-ACPI) vmt0at cpu0# VMware Tools #Xen PV support for PVH and HVM guests options XENPVHVM options XEN hypervisor*at mainbus?# Xen hypervisor xenbus* at hypervisor?# Xen virtual bus xencons*at hypervisor?# Xen virtual console xennet* at xenbus?# Xen virtual network interface xbd*at xenbus?# Xen virtual block device # experimental: PVH dom0 support #options DOM0OPS #pseudo-device xenevt #pseudo-device xvif #pseudo-device xbdback # Alternate buffer queue strategies for better responsiveness under high # disk I/O load. #options BUFQ_READPRIO options BUFQ_PRIOCSCAN # Diagnostic/debugging support options #options DIAGNOSTIC# inexpensive kernel consistency checks # XXX to be commented out on release
Re: compile kernel
Brad Spencer wrote: "pms-...@outlook.com" writes: Brad Spencer wrote: Todd Gruhn writes: [personal nit... it would be nice if the isa bus would be eliminated entirely, but there appears to be an edge case when compiling a XEN3_DOM0 kernel that requires it to be there... don't remember why...] Please, do not remove support for ISA and other older buses/hardware. That's why NetBSD is so awesome: wide hardware support :) Sure... but the last time I tried, you can't compile a kernel without it and a lot of hardware doesn't have ISA present any more. It is fine that it is supported, but it would be nice if it wasn't required. [snip] Ahh I get you now sir! Could you send me(or us all) your config file? Sounds like great weekend/summer project :)
Re: compile kernel
At Tue, 9 Apr 2024 07:24:11 +, Todd Gruhn wrote: Subject: Re: compile kernel > > On Mon, Apr 8, 2024 at 4:56 PM Brad Spencer wrote: > > > > [personal nit... it would be nice if the isa bus would be eliminated > > entirely, but there appears to be an edge case when compiling a > > XEN3_DOM0 kernel that requires it to be there... don't remember why...] > > I saw this. Split it. I only use 'pciide* at pci? ...' AND > 'ahcisata* at pci? ...' I've got several production and test servers (Dell machines), running Xen, that need pkcb0: pckbc0 at isa0 port 0x60-0x64 Some also have com ports on isa0 (here only one as Xen gets the other): com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, 1-byte FIFO -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpTmx1KFLoLI.pgp Description: OpenPGP Digital Signature
Re: compile kernel
"pms-...@outlook.com" writes: > Brad Spencer wrote: >> Todd Gruhn writes: >> >> >> [personal nit... it would be nice if the isa bus would be eliminated >> entirely, but there appears to be an edge case when compiling a >> XEN3_DOM0 kernel that requires it to be there... don't remember why...] >> > > Please, do not remove support for ISA and other older buses/hardware. > That's why NetBSD is so awesome: wide hardware support :) Sure... but the last time I tried, you can't compile a kernel without it and a lot of hardware doesn't have ISA present any more. It is fine that it is supported, but it would be nice if it wasn't required. [snip] -- Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
Re: compile kernel
Brad Spencer wrote: Todd Gruhn writes: [personal nit... it would be nice if the isa bus would be eliminated entirely, but there appears to be an edge case when compiling a XEN3_DOM0 kernel that requires it to be there... don't remember why...] Please, do not remove support for ISA and other older buses/hardware. That's why NetBSD is so awesome: wide hardware support :) Imagine: there could be some war going on, and some spread spectrum radio comms could work with ISA bus with little-bit of BSD inside ;)
Re: compile kernel
[personal nit... it would be nice if the isa bus would be eliminated entirely, but there appears to be an edge case when compiling a XEN3_DOM0 kernel that requires it to be there... don't remember why...] I saw this. Split it. I only use 'pciide* at pci? ...' AND 'ahcisata* at pci? ...' On Mon, Apr 8, 2024 at 4:56 PM Brad Spencer wrote: > > Todd Gruhn writes: > > > Is there a better way to config a netbsd kernel. > > > > GENERIC is getting so big. > > I assume that this is in reference to NetBSD/amd64... > > Use the MODULAR kernel?? This list might be incomplete, but it does > remove a number of drivers from the kernel. > > Edit GENERIC and remove / comment out what you don't want... this is, > perhaps, less desirable as the 'no ...' stuff works well. > > Use the GENERIC.local thing and put in 'no ...' lines for the stuff you > don't want > > Create a new config that includes GENERIC and has 'no ...' lines for the > stuff you don't want I did this for a GENERIC PVHcentric amd64 > kernel... it had a lot of 'no ... ' lines. > > Realize that a lot of systems today, both big and small, are pretty big > compared to XX years ago and the GENERIC kernel really isn't that > bad > > > [personal nit... it would be nice if the isa bus would be eliminated > entirely, but there appears to be an edge case when compiling a > XEN3_DOM0 kernel that requires it to be there... don't remember why...] > > > > > > > > -- > Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
RE: EXT MAIL : Re: compile kernel
Just comment the lines you don’t want.. And then to compile its Config GENERIC.new cd ../compile/GENERIC.new make depend && make -Original Message- From: netbsd-users-ow...@netbsd.org On Behalf Of Todd Gruhn Sent: Monday, April 8, 2024 8:12 AM To: Martin Husemann Cc: Chris Pinnock ; Netbsd-Users-List Subject: EXT MAIL : Re: compile kernel What about all the devices, SCSI, PCI, ISA, CardBus, aon other types of stuff? Too, many ethers, and MII / PHY stuff... On Mon, Apr 8, 2024 at 2:44 PM Martin Husemann wrote: > > On Mon, Apr 08, 2024 at 02:15:30PM +0100, Chris Pinnock wrote: > > > > > > > On 8 Apr 2024, at 10:11, Todd Gruhn wrote: > > > > > > Is there a better way to config a netbsd kernel. > > > > > > GENERIC is getting so big. > > > > In arch/*/conf you can copy the GENERIC kernel config file and edit > > the new file to remove drivers and features. (e.g. if you don?t use NFS, > > you can remove it.) Then run config with the new file. > > Another option (for many architectures) is to have a GENERIC.local > file (next to GENERIC in your arch's conf/ directory) and use that to > remove unwanted options from GENERIC. This avoids stale copies of > GENERIC when other changes happen to GENERIC. > > You use "no ..." statements in GENERIC.local, like: > > no file-system NFS > no file-system LFS > no options INET6 > no i915drmkms* > no radeon* > no nouveau* > > > Martin CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Re: compile kernel
Todd Gruhn writes: > Is there a better way to config a netbsd kernel. > > GENERIC is getting so big. I assume that this is in reference to NetBSD/amd64... Use the MODULAR kernel?? This list might be incomplete, but it does remove a number of drivers from the kernel. Edit GENERIC and remove / comment out what you don't want... this is, perhaps, less desirable as the 'no ...' stuff works well. Use the GENERIC.local thing and put in 'no ...' lines for the stuff you don't want Create a new config that includes GENERIC and has 'no ...' lines for the stuff you don't want I did this for a GENERIC PVHcentric amd64 kernel... it had a lot of 'no ... ' lines. Realize that a lot of systems today, both big and small, are pretty big compared to XX years ago and the GENERIC kernel really isn't that bad [personal nit... it would be nice if the isa bus would be eliminated entirely, but there appears to be an edge case when compiling a XEN3_DOM0 kernel that requires it to be there... don't remember why...] -- Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
Re: compile kernel
What about all the devices, SCSI, PCI, ISA, CardBus, aon other types of stuff? Too, many ethers, and MII / PHY stuff... On Mon, Apr 8, 2024 at 2:44 PM Martin Husemann wrote: > > On Mon, Apr 08, 2024 at 02:15:30PM +0100, Chris Pinnock wrote: > > > > > > > On 8 Apr 2024, at 10:11, Todd Gruhn wrote: > > > > > > Is there a better way to config a netbsd kernel. > > > > > > GENERIC is getting so big. > > > > In arch/*/conf you can copy the GENERIC kernel config file and edit the new > > file to remove drivers and features. (e.g. if you don?t use NFS, you can > > remove it.) > > Then run config with the new file. > > Another option (for many architectures) is to have a GENERIC.local file > (next to GENERIC in your arch's conf/ directory) and use that to remove > unwanted options from GENERIC. This avoids stale copies of GENERIC when > other changes happen to GENERIC. > > You use "no ..." statements in GENERIC.local, like: > > no file-system NFS > no file-system LFS > no options INET6 > no i915drmkms* > no radeon* > no nouveau* > > > Martin
Re: compile kernel
On Mon, Apr 08, 2024 at 02:15:30PM +0100, Chris Pinnock wrote: > > > > On 8 Apr 2024, at 10:11, Todd Gruhn wrote: > > > > Is there a better way to config a netbsd kernel. > > > > GENERIC is getting so big. > > In arch/*/conf you can copy the GENERIC kernel config file and edit the new > file to remove drivers and features. (e.g. if you don?t use NFS, you can > remove it.) > Then run config with the new file. Another option (for many architectures) is to have a GENERIC.local file (next to GENERIC in your arch's conf/ directory) and use that to remove unwanted options from GENERIC. This avoids stale copies of GENERIC when other changes happen to GENERIC. You use "no ..." statements in GENERIC.local, like: no file-system NFS no file-system LFS no options INET6 no i915drmkms* no radeon* no nouveau* Martin
Re: compile kernel
> On 8 Apr 2024, at 10:11, Todd Gruhn wrote: > > Is there a better way to config a netbsd kernel. > > GENERIC is getting so big. In arch/*/conf you can copy the GENERIC kernel config file and edit the new file to remove drivers and features. (e.g. if you don’t use NFS, you can remove it.) Then run config with the new file. KRgds C smime.p7s Description: S/MIME cryptographic signature
