Hi, during some big discussions in the last monts on various lists, one of the problems was that some people would like to use freebsd-update but can't as they are using a custom kernel. With all the kernel modules we provide, the need for a custom kernel should be small, but on the other hand, we do not provide a small kernel-skeleton where you can load just the modules you need. This should be easy to change. As a first step I took the generic kernel and removed all devices which are available as modules, e.g. the USB section consists now only of the USB_DEBUG option (so that the module is build like with the current generic kernel). I also removed some storage drivers which are not available as a module. The rationale is, that I can not remove CAM from the kernel config if I let those drivers inside (if those drivers are important enough, someone will probably fix the problem and add the missing pieces to generate a module). Such a kernel would cover situations where people compile their own kernel because they want to get rid of some unused kernel code (and maybe even need the memory this frees up). The question is, is this enough? Or asked differently, why are you compiling a custom kernel in a production environment (so I rule out debug options zhich are not enabled in GENERIC)? Are there options which you add which you can not add as a module (SW_WATCHDOG comes to my mind)? If yes, which ones and how important are they for you? Bye, Alexander. -- Cheit's Lament: If you help a friend in need, he is sure to remember you-- the next time he's in need. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
On Fri, Feb 10, 2012 at 02:56:04PM +0100, Alexander Leidinger wrote:> The question is, is this enough? Or asked differently, why are you > compiling a custom kernel in a production environment (so I rule out > debug options zhich are not enabled in GENERIC)? Are there options > which you add which you can not add as a module (SW_WATCHDOG comes to > my mind)? If yes, which ones and how important are they for you? >For me, the two big ones are IPSEC (which, as I understand it, we cannot ship with GENERIC due to export laws), and KDB_UNATTENDED. The latter may be a sysctl tunable, I never bothered to look. Regards, Glen
On Fri, Feb 10, 2012 at 02:56:04PM +0100, Alexander Leidinger wrote:> Hi, > > during some big discussions in the last monts on various lists, one > of the problems was that some people would like to use > freebsd-update but can't as they are using a custom kernel. With all > the kernel modules we provide, the need for a custom kernel should > be small, but on the other hand, we do not provide a small > kernel-skeleton where you can load just the modules you need. > > This should be easy to change. As a first step I took the generic > kernel and removed all devices which are available as modules, e.g. > the USB section consists now only of the USB_DEBUG option (so that > the module is build like with the current generic kernel). I also > removed some storage drivers which are not available as a module. > The rationale is, that I can not remove CAM from the kernel config > if I let those drivers inside (if those drivers are important > enough, someone will probably fix the problem and add the missing > pieces to generate a module). > > Such a kernel would cover situations where people compile their own > kernel because they want to get rid of some unused kernel code (and > maybe even need the memory this frees up). > > The question is, is this enough? Or asked differently, why are you > compiling a custom kernel in a production environment (so I rule out > debug options zhich are not enabled in GENERIC)? Are there options > which you add which you can not add as a module (SW_WATCHDOG comes > to my mind)? If yes, which ones and how important are they for you?I need (not on every machine, granted) IPSEC and MROUTING> Bye, > Alexander. > > -- > Cheit's Lament: > If you help a friend in need, he is sure to remember you-- > the next time he's in need. > > http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137Buki -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120210/7f6a7c9d/attachment.pgp
On 2012-02-10 14:56:04 (+0100), Alexander Leidinger <Alexander@Leidinger.net> wrote:> The question is, is this enough? Or asked differently, why are you > compiling a custom kernel in a production environment (so I rule out > debug options zhich are not enabled in GENERIC)? Are there options > which you add which you can not add as a module (SW_WATCHDOG comes > to my mind)? If yes, which ones and how important are they for you? >VIMAGE and IPSEC I currently "require" both of them. The VIMAGE is sort of optional. I could run everything unjailed, but I prefer this. IPSEC is required, unless I add a separate device. That's for a little home gateway (HP Microserver thingy), doing file serving (NFS/ZFS), mail, web, backup, ... Regards, Kristof
On Fri, Feb 10, 2012 at 02:56:04PM +0100, Alexander Leidinger wrote:> Hi, > > during some big discussions in the last monts on various lists, one of > the problems was that some people would like to use freebsd-update but > can't as they are using a custom kernel. With all the kernel modules > we provide, the need for a custom kernel should be small, but on the > other hand, we do not provide a small kernel-skeleton where you can > load just the modules you need. > > This should be easy to change. As a first step I took the generic > kernel and removed all devices which are available as modules, e.g. > the USB section consists now only of the USB_DEBUG option (so that the > module is build like with the current generic kernel). I also removed > some storage drivers which are not available as a module. The > rationale is, that I can not remove CAM from the kernel config if I > let those drivers inside (if those drivers are important enough, > someone will probably fix the problem and add the missing pieces to > generate a module). > > Such a kernel would cover situations where people compile their own > kernel because they want to get rid of some unused kernel code (and > maybe even need the memory this frees up). > > The question is, is this enough? Or asked differently, why are you > compiling a custom kernel in a production environment (so I rule out > debug options zhich are not enabled in GENERIC)? Are there options > which you add which you can not add as a module (SW_WATCHDOG comes to > my mind)? If yes, which ones and how important are they for you?- INET without INET6 - SOFTUPDATES, UFS_ACL, AUDIT, SCTP (left out for embedded devices) - Bj?rn may add INET6 without INET - SCHED_ULE vs. SCHED_4BSD - No vga console/atkbd/psm for embedded devices - CPU_SOEKRIS, CPU_GEODE, CPU_ELAN, NO_SWAPPING for embedded devices - IPSTEALTH, IPSEC, IPSEC_FILTERTUNNEL, IPFILTER, ALTQ for firewalls - probably more I also always specify exactly one CPU type (on i386), know it made a difference in the 386/486/586 era but am not sure how much difference it makes nowadays. HTH Paul Schenkeveld
On 10/2/2012 15:56, Alexander Leidinger wrote:> Hi, > > during some big discussions in the last monts on various lists, one of > the problems was that some people would like to use freebsd-update but > can't as they are using a custom kernel. With all the kernel modules we > provide, the need for a custom kernel should be small, but on the other > hand, we do not provide a small kernel-skeleton where you can load just > the modules you need. > > This should be easy to change. As a first step I took the generic kernel > and removed all devices which are available as modules, e.g. the USB > section consists now only of the USB_DEBUG option (so that the module is > build like with the current generic kernel). I also removed some storage > drivers which are not available as a module. The rationale is, that I > can not remove CAM from the kernel config if I let those drivers inside > (if those drivers are important enough, someone will probably fix the > problem and add the missing pieces to generate a module). > > Such a kernel would cover situations where people compile their own > kernel because they want to get rid of some unused kernel code (and > maybe even need the memory this frees up). > > The question is, is this enough? Or asked differently, why are you > compiling a custom kernel in a production environment (so I rule out > debug options which are not enabled in GENERIC)? Are there options which > you add which you can not add as a module (SW_WATCHDOG comes to my > mind)? If yes, which ones and how important are they for you?Hello, we are currently using on every server (in order to maintain a single custom kernel) the following options: IPFIREWALL IPFIREWALL_DEFAULT_TO_ACCEPT IPFIREWALL_FORWARD ROUTETABLES=n Soon, we will also add: IPSEC IPSEC_FILTERTUNNEL IPSEC_NAT_T crypto enc Finally, once we upgrade our jail setup VIMAGE will be also a must. Regards, Panagiotis -- Panagiotis J. Christias Network Management Center p.christias@noc.ntua.gr National Technical Univ. of Athens, GREECE
Alexander Leidinger wrote:> during some big discussions in the last monts on various lists, one of > the problems was that some people would like to use freebsd-update but > can't as they are using a custom kernel. With all the kernel modules we > provide, the need for a custom kernel should be small, but on the other > hand, we do not provide a small kernel-skeleton where you can load just > the modules you need. > > This should be easy to change. As a first step I took the generic kernel > and removed all devices which are available as modules, e.g. the USB > section consists now only of the USB_DEBUG option (so that the module is > build like with the current generic kernel). I also removed some storage > drivers which are not available as a module. The rationale is, that I > can not remove CAM from the kernel config if I let those drivers inside > (if those drivers are important enough, someone will probably fix the > problem and add the missing pieces to generate a module). > > Such a kernel would cover situations where people compile their own > kernel because they want to get rid of some unused kernel code (and > maybe even need the memory this frees up). > > The question is, is this enough? Or asked differently, why are you > compiling a custom kernel in a production environment (so I rule out > debug options zhich are not enabled in GENERIC)? Are there options which > you add which you can not add as a module (SW_WATCHDOG comes to my > mind)? If yes, which ones and how important are they for you?The list would be too long for me, that's a sample what I add to my MINIMAL after stripping GENERIC: option DEVICE_POLLING option BPF_JITTER option DIRECTIO option SC_ALT_MOUSE_IMAGE option SC_MOUSE_CHAR=0x3 option ZERO_COPY_SOCKETS option SW_WATCHDOG option ALTQ option ALTQ_CBQ option ALTQ_RED option ALTQ_RIO option ALTQ_HFSC option ALTQ_CDNR option ALTQ_PRIQ option ALTQ_NOPCC device atpic device mptable I even don't use them on most machines however I prefer to build all machines from one kernel config however even this is impossible because for example I can't select scheduler by modules. Some point can be superseded in future for example current work on ULE seems promising. For example, why there are no modules for atpic and mptable? I don't need them on most machines but I can't load them at boot time. -- Sphinx of black quartz judge my vow.
On Fri, February 10, 2012 11:56, Alexander Leidinger wrote:> Hi, > > during some big discussions in the last monts on various lists, one of > the problems was that some people would like to use freebsd-update but > can't as they are using a custom kernel. With all the kernel modules > we provide, the need for a custom kernel should be small, but on the > other hand, we do not provide a small kernel-skeleton where you can > load just the modules you need. > > This should be easy to change. As a first step I took the generic > kernel and removed all devices which are available as modules, e.g. > the USB section consists now only of the USB_DEBUG option (so that the > module is build like with the current generic kernel). I also removed > some storage drivers which are not available as a module. The > rationale is, that I can not remove CAM from the kernel config if I > let those drivers inside (if those drivers are important enough, > someone will probably fix the problem and add the missing pieces to > generate a module). > > Such a kernel would cover situations where people compile their own > kernel because they want to get rid of some unused kernel code (and > maybe even need the memory this frees up). > > The question is, is this enough? Or asked differently, why are you > compiling a custom kernel in a production environment (so I rule out > debug options zhich are not enabled in GENERIC)? Are there options > which you add which you can not add as a module (SW_WATCHDOG comes to > my mind)? If yes, which ones and how important are they for you?Its a great thing this Alexander, but for me mainly I need PF+ALTQ and soekris stuff (apart from things other said before). matheus -- We will call you Cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style
On 10. Feb 2012, at 13:56 , Alexander Leidinger wrote:> Hi, > > during some big discussions in the last monts on various lists, one of the problems was that some people would like to use freebsd-update but can't as they are using a custom kernel. With all the kernel modules we provide, the need for a custom kernel should be small, but on the other hand, we do not provide a small kernel-skeleton where you can load just the modules you need. > > This should be easy to change. As a first step I took the generic kernel and removed all devices which are available as modules, e.g. the USB section consists now only of the USB_DEBUG option (so that the module is build like with the current generic kernel). I also removed some storage drivers which are not available as a module. The rationale is, that I can not remove CAM from the kernel config if I let those drivers inside (if those drivers are important enough, someone will probably fix the problem and add the missing pieces to generate a module).And you completely seem to have missed the discussion about a device ID DB and loader being able to probe and load them for you? With that sound, firewire, but also NICs and storage drivers can mostly go away... But it needs infrastructure... lots of ... feel free to resume that thread but stable@ is obviously the wrong place.> Such a kernel would cover situations where people compile their own kernel because they want to get rid of some unused kernel code (and maybe even need the memory this frees up). > > The question is, is this enough? Or asked differently, why are you compiling a custom kernel in a production environment (so I rule out debug options zhich are not enabled in GENERIC)? Are there options which you add which you can not add as a module (SW_WATCHDOG comes to my mind)? If yes, which ones and how important are they for you?As a lot of the results will show... various parts of the network stack being loadable, which is not as easy as it sounds, especially making them unloadable again currently ... /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do!
I've done this a few times. The /boot/loader takes a _long_ time to suck in the 25 odd modules my eeepc requires to load a completely modular kernel. It takes a _very long_ time to suck these in over USB. It's a great idea and I think we should start down this path in the 10-CURRENT trajectory but those load times need to be tweaked if possible. Adrian
On Fri, Feb 10, 2012 at 02:56:04PM +0100, Alexander Leidinger wrote:> during some big discussions in the last monts on various lists, one > of the problems was that some people would like to use > freebsd-update but can't as they are using a custom kernel. With all > the kernel modules we provide, the need for a custom kernel should > be small, but on the other hand, we do not provide a small > kernel-skeleton where you can load just the modules you need.My below comments apply to RELENG_8, amd64. Just noting that here. I have no plans to upgrade to RELENG_9 or newer.> This should be easy to change. As a first step I took the generic > kernel and removed all devices which are available as modules, e.g. > the USB section consists now only of the USB_DEBUG option (so that > the module is build like with the current generic kernel). I also > removed some storage drivers which are not available as a module. > The rationale is, that I can not remove CAM from the kernel config > if I let those drivers inside (if those drivers are important > enough, someone will probably fix the problem and add the missing > pieces to generate a module).This is a core (meaning "key") problem as I see it. There is no definitive list of what drivers can/will work as modules vs. being compiled in to the kernel statically. Furthermore, there is evidence on the mailing lists where users experience different behaviour in drivers when built as modules than if statically included: em(4) is one such example (I can dig up the post if needed). Jack often asks me why we include em(4) statically. :-)> Such a kernel would cover situations where people compile their own > kernel because they want to get rid of some unused kernel code (and > maybe even need the memory this frees up). > > The question is, is this enough? Or asked differently, why are you > compiling a custom kernel in a production environment (so I rule out > debug options zhich are not enabled in GENERIC)? Are there options > which you add which you can not add as a module (SW_WATCHDOG comes > to my mind)? If yes, which ones and how important are they for you?Excellent question, and I would love to share with folks the list of things we tweak in our kernel config vs. GENERIC: * Removal: option INET6 * Removal: option SCTP * Removal: option COMPAT_FREEBSD32 * Removal: option COMPAT_FREEBSD4 * Removal: option COMPAT_FREEBSD5 * Removal: option COMPAT_FREEBSD6 * Removal: option COMPAT_FREEBSD7 * Setting: option PRINTF_BUFR_SIZE=256 * Addition: option KDTRACE_HOOKS * Addition: option FLOWTABLE - Note: Despite this, we disable use of flowtable via sysctl due to severe bugs as we have no indication this has been fixed: http://lists.freebsd.org/pipermail/freebsd-stable/2010-November/060289.html * Addition: option BREAK_TO_DEBUGGER * Addition: option ALT_BREAK_TO_DEBUGGER * Addition: option KDB * Addition: option KDB_TRACE * Addition: option DDB * Addition: option DDB_NUMSYM * Addition: option GDB * Addition: option KTR * Addition: option KTR_ENTRIES=262144 * Addition: option KTR_COMPILE=(KTR_SCHED) * Addition: option KTR_MASK=(KTR_SCHED) * Removal: device ata - Note: Our config has the following comment: # NOTE: "device ata" is missing because we use the Modular ATA core # to only include the ATA-related drivers we need (e.g. AHCI). * Removal: device atapifd * Removal: device atapist * Removal: All device/options relating to SCSI controllers * Addition: device atacore * Addition: device ataisa * Addition: device atapci * Addition: device ataahci * Addition: device ataintel * Removal: device ch * Removal: device sa * Removal: All device/options pertaining to RAID controllers * Removal: All device/options pertaining to PCMCIA/CardBus * Removal: All device/options pertaining to parallel ports * Removal: device puc * Removal: All PCI Ethernet NICs (with and without miibus), with the exception being em * Removal: All ISA Ethernet NICs * Removal: All Wireless NICs * Removal: device vlan * Removal: device tun * Removal: device gif * Removal: device faith * Removal: option USB_DEBUG * Removal: device ulpt * Removal: All device/options pertaining to USB serial devices * Removal: All device/options pertaining to USB Ethernet devices * Removal: All device/options pertaining to USB Wireless devices * Removal: All device/options pertaining to FireWire * Addition: device coretemp * Addition: device smbus * Addition: device smb * Addition: device ichsmb * Addition: device ichwd - Note: We do not use features of this driver given known problems with the watchdog firing during ddb> and similar environments. I have no idea if this has been fixed, but I do remember it being confirmed as a problem. * Addition: options ALTQ * Addition: options ALTQ_CBQ * Addition: options ALTQ_RED * Addition: options ALTQ_RIO * Addition: options ALTQ_HFSC * Addition: options ALTQ_CDNR * Addition: options ALTQ_PRIQ * Addition: options ALTQ_NOPCC I want to note here: the pf ALTQ options are a pain in the butt, quite honestly. I've found in the past that removing the ones you don't use won't result in a successful build, thus one must include them all. We do need ALTQ support though, for rate-limiting capability. The NOPCC option is needed for SMP builds, which makes me wonder what the state of SMP is in this regard -- meaning, on non-SMP builds, is it still safe to include ALTQ_NOPCC? Now, most of the device-related ones -- ASSUMING they can be used reliably as kernel modules -- can probably be ignored (meaning if you strip them out, per your proposal, that's fine). However, the list of options above still stands. Also, there are obviously kernel modules which we're using dynamically, such as ahci.ko (/boot/loader.conf ahci_load="yes") and some others: # kldstat Id Refs Address Size Name 1 20 0xffffffff80100000 1d34f30 kernel 2 1 0xffffffff81e36000 11e48 ahci.ko 3 1 0xffffffff82012000 1313a8 zfs.ko 4 1 0xffffffff82144000 1ff1 opensolaris.ko 5 1 0xffffffff82146000 28c93 pf.ko 6 1 0xffffffff8216f000 7f8 accf_http.ko 7 1 0xffffffff82170000 1f0 accf_data.ko So in this case, ZFS is loaded dynamically via zfs_enable="yes" in rc.conf, as is pf. The accf_* combo is pulled in in real-time when one uses Apache with apache22_http_accept_enable="yes". All the other options you see that we adjust we have legitimate need for. I cannot stress (to you and others) how important it is to have many of the debugging options in there; in the case of a kernel panic, in almost every case on the mailing lists, the first response from developers is "can you drop to ddb and..." I realise for folks running remote/embedded environments these probably aren't what they want, but for the majority I see them as being needed more and more I watch the responses from developers. Finally, just throwing this out there: does anyone know if you can include ALT_BREAK_TO_DEBUGGER by itself, without BREAK_TO_DEBUGGER? E.g. we only want <CR>~<Ctrl-b> inducing a break to ddb, not serial break. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |
"Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> wrote:> various parts of the network stack being loadable, which is not > as easy as it sounds, especially making them unloadable again > currently ...Seems to me unloadability does not matter to the case under discussion, which is modularizing the kernel to reduce the number of cases in which a custom kernel is needed. How much real functional difference is there between "built in" and "loaded permanently at boot"?
Le ven 10 f?v 12 ? 14:56:04 +0100, Alexander Leidinger <Alexander@Leidinger.net> ?crivait?:> Hi,Hello,> The question is, is this enough? Or asked differently, why are you > compiling a custom kernel in a production environment (so I rule out > debug options zhich are not enabled in GENERIC)? Are there options > which you add which you can not add as a module (SW_WATCHDOG comes to > my mind)? If yes, which ones and how important are they for you?Not very important, but since you are asking, is there another place to put options to atkbd and sc, like these ones: options ATKBD_DFLT_KEYMAP # specify the built-in keymap makeoptions ATKBD_DFLT_KEYMAP=fr.iso.acc options SC_KERNEL_CONS_ATTR=(FG_LIGHTGREEN|BG_BLACK) options SC_KERNEL_CONS_REV_ATTR=(FG_WHITE|BG_GREEN) options SC_NORM_REV_ATTR=(FG_WHITE|BG_BLUE) Regards, -- Th. Thomas. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120211/a48f1791/attachment.pgp
On Sat, 11 Feb 2012 13:40:41 +0100 Thierry Thomas <thierry@FreeBSD.org> wrote:> Le ven 10 f?v 12 ? 14:56:04 +0100, Alexander Leidinger > <Alexander@Leidinger.net> ?crivait?: > > Hi, > > Hello, > > > The question is, is this enough? Or asked differently, why are you > > compiling a custom kernel in a production environment (so I rule out > > debug options zhich are not enabled in GENERIC)? Are there options > > which you add which you can not add as a module (SW_WATCHDOG comes > > to my mind)? If yes, which ones and how important are they for you? > > Not very important, but since you are asking, is there another place > to put options to atkbd and sc, like these ones: > > options ATKBD_DFLT_KEYMAP # specify the built-in keymap > makeoptions ATKBD_DFLT_KEYMAP=fr.iso.acc > > options SC_KERNEL_CONS_ATTR=(FG_LIGHTGREEN|BG_BLACK) > options SC_KERNEL_CONS_REV_ATTR=(FG_WHITE|BG_GREEN) > options SC_NORM_REV_ATTR=(FG_WHITE|BG_BLUE)No, there is no other way to add the keymap to the kernel directly (if you want to have it working correctly in single-user mode) instead of loading it with rc.conf. I do not know if you can change the colors with vidcontrol, but if you can, I do not expect this to be a problem for single-user mode. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
On Sat, 11 Feb 2012 07:33:08 -0800 perryh@pluto.rain.com wrote:> "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> wrote: > > > various parts of the network stack being loadable, which is not > > as easy as it sounds, especially making them unloadable again > > currently ... > > Seems to me unloadability does not matter to the case under > discussion, which is modularizing the kernel to reduce theCorrect.> number of cases in which a custom kernel is needed. How much > real functional difference is there between "built in" and > "loaded permanently at boot"?For what I want to achieve: nearly zero compared to GENERIC (there will be differences, more when I present the result for discussion). Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
Alexander Leidinger <Alexander@Leidinger.net> wrote:> On Sat, 11 Feb 2012 13:40:41 +0100 Thierry Thomas <thierry@FreeBSD.org> > wrote: > > is there another place to put options to atkbd and sc, like > > these ones: > > > > options ATKBD_DFLT_KEYMAP # specify the built-in keymap > > makeoptions ATKBD_DFLT_KEYMAP=fr.iso.acc > > ... > > No, there is no other way to add the keymap to the kernel directly > (if you want to have it working correctly in single-user mode) > instead of loading it with rc.conf.Might it be feasible to make it into a sysctl, so it could be set in loader.conf?
On Sun, 12 Feb 2012 03:05:02 -0800 perryh@pluto.rain.com wrote:> Alexander Leidinger <Alexander@Leidinger.net> wrote: > > On Sat, 11 Feb 2012 13:40:41 +0100 Thierry Thomas > > <thierry@FreeBSD.org> wrote: > > > is there another place to put options to atkbd and sc, like > > > these ones: > > > > > > options ATKBD_DFLT_KEYMAP # specify the built-in > > > keymap makeoptions ATKBD_DFLT_KEYMAP=fr.iso.acc > > > ... > > > > No, there is no other way to add the keymap to the kernel directly > > (if you want to have it working correctly in single-user mode) > > instead of loading it with rc.conf. > > Might it be feasible to make it into a sysctl, so it could be set in > loader.conf?There is already a way to configure this as soon as you have a working userland. What this setting is doing is to replace the compiled-in default keymap with a different one, so that you have the one which matches your keyboard even when you enter the very first keystrokes in single-user mode (root-pw, path to shell, ...). Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
Quoting Paul Schenkeveld <freebsd@psconsult.nl> (from Fri, 10 Feb 2012 15:44:50 +0100):> On Fri, Feb 10, 2012 at 02:56:04PM +0100, Alexander Leidinger wrote: >> Hi, >> >> during some big discussions in the last monts on various lists, one of >> the problems was that some people would like to use freebsd-update but >> can't as they are using a custom kernel. With all the kernel modules >> we provide, the need for a custom kernel should be small, but on the >> other hand, we do not provide a small kernel-skeleton where you can >> load just the modules you need. >> >> This should be easy to change. As a first step I took the generic >> kernel and removed all devices which are available as modules, e.g. >> the USB section consists now only of the USB_DEBUG option (so that the >> module is build like with the current generic kernel). I also removed >> some storage drivers which are not available as a module. The >> rationale is, that I can not remove CAM from the kernel config if I >> let those drivers inside (if those drivers are important enough, >> someone will probably fix the problem and add the missing pieces to >> generate a module). >> >> Such a kernel would cover situations where people compile their own >> kernel because they want to get rid of some unused kernel code (and >> maybe even need the memory this frees up). >> >> The question is, is this enough? Or asked differently, why are you >> compiling a custom kernel in a production environment (so I rule out >> debug options zhich are not enabled in GENERIC)? Are there options >> which you add which you can not add as a module (SW_WATCHDOG comes to >> my mind)? If yes, which ones and how important are they for you? > > - INET without INET6 > - SOFTUPDATES, UFS_ACL, AUDIT, SCTP (left out for embedded devices) > - Bj?rn may add INET6 without INET > - SCHED_ULE vs. SCHED_4BSD > - No vga console/atkbd/psm for embedded devices > - CPU_SOEKRIS, CPU_GEODE, CPU_ELAN, NO_SWAPPING for embedded devicesEmbedded devices are out of the scope of this, normally you do a lot of other modifictions to such systems anyway, so a custom kernel should be not a big problem. I will also not touch the dual-stack part of the kernel config (it shall still allow the generic purpose computing like the GERNERIC config).> - IPSTEALTH, IPSEC, IPSEC_FILTERTUNNEL, IPFILTER, ALTQ for firewallsRequest noted.> I also always specify exactly one CPU type (on i386), know it made a > difference in the 386/486/586 era but am not sure how much difference > it makes nowadays.The 386 part (which we do not have anymore in GENERIC) made a difference, the rest doesn't hurt in the kernel. Bye, Alexander. -- Smuggling... It's not just a job, it's an adventure! -- paid for by your local Colombian recruiting office http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
Alexander Leidinger
2012-Feb-14 11:38 UTC
Custom kernel poll summary (was: Re: Reducing the need to compile a custom kernel)
Quoting Alexander Leidinger <Alexander@Leidinger.net> (from Fri, 10 Feb 2012 14:56:04 +0100):> Such a kernel would cover situations where people compile their own > kernel because they want to get rid of some unused kernel code (and > maybe even need the memory this frees up). > > The question is, is this enough? Or asked differently, why are you > compiling a custom kernel in a production environment (so I rule out > debug options zhich are not enabled in GENERIC)? Are there options > which you add which you can not add as a module (SW_WATCHDOG comes > to my mind)? If yes, which ones and how important are they for you?Here is what I got, the first column is the number of requests, the second what is requested, and the 3rd my comments (basically it means, if there is a comment, it is not needed/possible to include in a modular kernel): ---snip--- 5 IPSEC 4 ALTQ 2 VIMAGE -> not production ready (bz) 2 SW_WATCHDOG 2 IPSEC_FILTERTUNNEL -> obsolete according to bz 2 IPFIREWALL_DEFAULT_TO_ACCEPT -> loader.conf: net.inet.ip.fw.default_to_accept 2 IPFIREWALL -> loader.conf: ipfw_load='YES' 2 HZ=1000 -> loader.conf: kern.hz 2 DEVICE_POLLING -> ifconfig in 9.0 handles this at runtime? 1 enc 1 ZERO_COPY_SOCKETS -> has known problems? can't find the reference, but I removed it from my kernels 1 SC_* options -> not a generic setting, will not include 1 ROUTETABLES=n -> bz is working on this 1 QUOTA 1 PF -> loader.conf: pf_load='YES' 1 MROUTING -> loader.conf: ip_mroute='YES'? 1 KTR -> rare use case, kernel recompile is OK 1 KDTRACE_HOOKS -> legal review needed 1 KDB_UNATTENDED -> re@ wants this, but has reservations 1 KDB_TRACE -> re@ wants this, but has reservations 1 KDB -> re@ wants this, but has reservations 1 IPSTEALTH 1 IPSEC_NAT_T 1 IPFIREWALL_VERBOSE_LIMIT=5 1 IPFIREWALL_VERBOSE 1 IPFIREWALL_FORWARD -> performance impact too big if unused (julian) 1 IPFILTER -> 2/3 firewalls can be loaded... and this one is not really maintained anymore 1 IPDIVERT -> loader.conf: ipdivert_load='YES' 1 GDB 1 FLOWTABLE 1 DUMMYNET -> loader.conf: dummynet_load='YES' 1 DIRECTIO 1 DDB_NUMSYM 1 DDB 1 BREAK_TO_DEBUGGER -> loader.conf: debug.kdb.break_to_debugger 1 BPF_JITTER 1 ALT_BREAK_TO_DEBUGGER -> loader.conf: debug.kdb.alt_break_to_debugger ---snip--- Yes, this poll is not representative... So... what's the impact of including the following options into a kernel which is intended to be modular, respectively are there reasons to _not_ include one of the following? ---snip--- 5 IPSEC -> we do not have a separate cryto dist, so it should be possible to include in a kernel now... legal advise needed 4 ALTQ* -> does add code to the pf module other impact? 2 SW_WATCHDOG -> should not hurt if not enabled in rc.conf 1 enc -> together with IPSEC 1 IPSTEALTH -> changes ipfw module only? 1 IPSEC_NAT_T 1 IPFIREWALL_VERBOSE_LIMIT=5 -> changes ipfw module only? loader tunable? 1 IPFIREWALL_VERBOSE -> changes ipfw module only? loader tunable? 1 FLOWTABLE 1 DIRECTIO 1 BPF_JITTER ---snip--- Bye, Alexander. -- Q: What is purple and concord the world? A: Alexander the Grape. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
Attilio Rao
2012-Feb-14 13:08 UTC
Custom kernel poll summary (was: Re: Reducing the need to compile a custom kernel)
2012/2/14, Alexander Leidinger <Alexander@leidinger.net>:> Quoting Alexander Leidinger <Alexander@Leidinger.net> (from Fri, 10 > Feb 2012 14:56:04 +0100): > >> Such a kernel would cover situations where people compile their own >> kernel because they want to get rid of some unused kernel code (and >> maybe even need the memory this frees up). >> >> The question is, is this enough? Or asked differently, why are you >> compiling a custom kernel in a production environment (so I rule out >> debug options zhich are not enabled in GENERIC)? Are there options >> which you add which you can not add as a module (SW_WATCHDOG comes >> to my mind)? If yes, which ones and how important are they for you? > > Here is what I got, the first column is the number of requests, the > second what is requested, and the 3rd my comments (basically it means, > if there is a comment, it is not needed/possible to include in a > modular kernel):...> 2 SW_WATCHDOGThis can become a module with very little effort I guess. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein
Stefan Bethke
2012-Feb-17 19:48 UTC
Custom kernel poll summary (was: Re: Reducing the need to compile a custom kernel)
Am 14.02.2012 um 12:37 schrieb Alexander Leidinger:> 1 FLOWTABLEThe last time I included this in a kernel it seemed to have odd effects on TCP connections. Admittedly, that was probably two years or so ago, and I never bothered to find out what was happening in detail. Is it safe now? Stefan -- Stefan Bethke <stb@lassitu.de> Fon +49 151 14070811
Hi! Finally someone thought about this! My 5 cents: IPFIREWALL_FORWARD <- no comment)) options VIMAGE <- not yet production ready, but keep in mind it Forgot this two very usefull options: options RACCT <- resource limits for jail and etc. options RCTL <- resource limits for jail and etc. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Reducing-the-need-to-compile-a-custom-kernel-tp5472542p5504065.html Sent from the freebsd-stable mailing list archive at Nabble.com.