Re: CVS commit: src/sys/arch/i386/conf
On Fri, 22 Nov 2013, Jeff Rizzo wrote: Modified Files: src/sys/arch/i386/conf: ALL Log Message: Comment out npf for now, as we can't have both NPF and PF in the same kernel It used to be possible to have npf and pf in the same kernel. The kernel I am running now (built a few weeks ago) has both. I think it's important for users to be able to have both. If I want to migrate from pf to npf, then part of my testing would probably involve switching back and forth a few times to check that the npf rules do the same job as the pf rules, and I would want to be able to do that without booting a different kernel for every test. - rmind has said he'll address this eventually, OK. --apb (Alan Barrett)
Re: CVS commit: src/sys/arch/i386/conf
On 11/23/13 4:50 AM, Marc Balmer wrote: Zitat von Jeff Rizzo r...@netbsd.org: Module Name:src Committed By:riz Date:Fri Nov 22 18:58:01 UTC 2013 Modified Files: src/sys/arch/i386/conf: ALL Log Message: Comment out npf for now, as we can't have both NPF and PF in the same kernel - rmind has said he'll address this eventually, and for now PF is more likely to have unnoticed breakage. ALL now builds again! Wouldn't it make a more sense to disable pf since npf sees actual development, so testing it would actually help (and ALL is not meant to be run anyways)? To me compile testing npf would make much more sense than pf... ymmv. I did think about it, and I believe I laid out my reasoning in the commit message. +j
Re: CVS commit: src/sys/arch/i386/conf
Zitat von Jeff Rizzo r...@netbsd.org: Module Name:src Committed By: riz Date: Fri Nov 22 18:58:01 UTC 2013 Modified Files: src/sys/arch/i386/conf: ALL Log Message: Comment out npf for now, as we can't have both NPF and PF in the same kernel - rmind has said he'll address this eventually, and for now PF is more likely to have unnoticed breakage. ALL now builds again! Wouldn't it make a more sense to disable pf since npf sees actual development, so testing it would actually help (and ALL is not meant to be run anyways)? To me compile testing npf would make much more sense than pf... ymmv. To generate a diff of this commit: cvs rdiff -u -r1.364 -r1.365 src/sys/arch/i386/conf/ALL Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. This message was sent using IMP, the Internet Messaging Program.
Re: CVS commit: src/sys/arch/i386/conf
On Wed, 23 Oct 2013, Matt Thomas wrote: Module Name:src Committed By: matt Date: Wed Oct 23 17:26:08 UTC 2013 Modified Files: src/sys/arch/i386/conf: GENERIC XEN3_DOM0 Log Message: Add xhci device When do we get a xhci(4) man page? :) - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: CVS commit: src/sys/arch/i386/conf
On Wed, Oct 23, 2013 at 10:37:15AM -0700, Paul Goyette wrote: On Wed, 23 Oct 2013, Matt Thomas wrote: Module Name: src Committed By:matt Date:Wed Oct 23 17:26:08 UTC 2013 Modified Files: src/sys/arch/i386/conf: GENERIC XEN3_DOM0 Log Message: Add xhci device When do we get a xhci(4) man page? :) Also: ALL is missing from the list. - Jukka.
Re: CVS commit: src/sys/arch/i386/conf
On Oct 23, 2013, at 11:42 AM, Jukka Ruohonen jruoho...@iki.fi wrote: On Wed, Oct 23, 2013 at 10:37:15AM -0700, Paul Goyette wrote: On Wed, 23 Oct 2013, Matt Thomas wrote: Module Name:src Committed By: matt Date: Wed Oct 23 17:26:08 UTC 2013 Modified Files: src/sys/arch/i386/conf: GENERIC XEN3_DOM0 Log Message: Add xhci device When do we get a xhci(4) man page? :) Also: ALL is missing from the list. That's because ALL already has xhci in it.
Re: CVS commit: src/sys/arch/i386/conf
On Sat, Apr 07, 2012 at 01:40:42AM -0400, Christos Zoulas wrote: Module Name: src Committed By: christos Date: Sat Apr 7 05:40:42 UTC 2012 Modified Files: src/sys/arch/i386/conf: GENERIC Log Message: add apple autodiscovery That needs to be added to the ALL config too. Bernd
Re: CVS commit: src/sys/arch/i386/conf
Am 29.08.11 11:38, schrieb Jukka Ruohonen: On Sat, Aug 27, 2011 at 09:28:56AM +, Marc Balmer wrote: Module Name: src Committed By:mbalmer Date:Sat Aug 27 09:28:56 UTC 2011 Modified Files: src/sys/arch/i386/conf: GENERIC Log Message: Enable some gpio devices. Is onewire(4) really something to be enabled by default on i386? Yes, why not?. It is small enough and lets you access cheap temperature sensors via gpiow(4).
Re: CVS commit: src/sys/arch/i386/conf
On Mon, Aug 29, 2011 at 02:48:52PM +0200, Marc Balmer wrote: Am 29.08.11 11:38, schrieb Jukka Ruohonen: On Sat, Aug 27, 2011 at 09:28:56AM +, Marc Balmer wrote: Module Name: src Committed By: mbalmer Date: Sat Aug 27 09:28:56 UTC 2011 Modified Files: src/sys/arch/i386/conf: GENERIC Log Message: Enable some gpio devices. Is onewire(4) really something to be enabled by default on i386? Yes, why not?. It is small enough and lets you access cheap temperature sensors via gpiow(4). Just that I have never seen a i386 system with onewire(4). (GENERIC as in: something common or descriptive for all members.) - Jukka.
Re: CVS commit: src/sys/arch/i386/conf
Am 29.08.11 14:53, schrieb Jukka Ruohonen: On Mon, Aug 29, 2011 at 02:48:52PM +0200, Marc Balmer wrote: Am 29.08.11 11:38, schrieb Jukka Ruohonen: On Sat, Aug 27, 2011 at 09:28:56AM +, Marc Balmer wrote: Module Name: src Committed By: mbalmer Date: Sat Aug 27 09:28:56 UTC 2011 Modified Files: src/sys/arch/i386/conf: GENERIC Log Message: Enable some gpio devices. Is onewire(4) really something to be enabled by default on i386? Yes, why not?. It is small enough and lets you access cheap temperature sensors via gpiow(4). Just that I have never seen a i386 system with onewire(4). with gpioow(4) you can use it over gpio(4), and means many system, e.g. all of Soekris, Alix, etc. (GENERIC as in: something common or descriptive for all members.) - Jukka.
Re: CVS commit: src/sys/arch/i386/conf
On Mon, Aug 29, 2011 at 02:58:32PM +0200, Marc Balmer wrote: Am 29.08.11 14:53, schrieb Jukka Ruohonen: On Mon, Aug 29, 2011 at 02:48:52PM +0200, Marc Balmer wrote: Am 29.08.11 11:38, schrieb Jukka Ruohonen: On Sat, Aug 27, 2011 at 09:28:56AM +, Marc Balmer wrote: Module Name: src Committed By:mbalmer Date:Sat Aug 27 09:28:56 UTC 2011 Modified Files: src/sys/arch/i386/conf: GENERIC Log Message: Enable some gpio devices. Is onewire(4) really something to be enabled by default on i386? Yes, why not?. It is small enough and lets you access cheap temperature sensors via gpiow(4). Just that I have never seen a i386 system with onewire(4). with gpioow(4) you can use it over gpio(4), and means many system, e.g. all of Soekris, Alix, etc. Ok, I stand corrected. And then I should've seen it on i386... - Jukka.
Re: CVS commit: src/sys/arch/i386/conf
On Mon, 08 Aug 2011, Jared D. McNeill wrote: Modified Files: src/sys/arch/i386/conf: GENERIC Log Message: remove dtv (available as a module) If you remove anything from GENERIC on the grounds that it is available as a module, then please add the same item to MONOLITHIC, so that MONOLITHIC remains more or less equivalent to GENERIC with most modules preloaded. Whether or not available as a module is a good reason for removing something from GENERIC is a separate topic which I will not consider in this message. --apb (Alan Barrett)
Re: CVS commit: src/sys/arch/i386/conf
On Tue, Aug 09, 2011 at 09:44:09AM +0200, Alan Barrett wrote: Whether or not available as a module is a good reason for removing something from GENERIC is a separate topic which I will not consider in this message. Fortunately, people can vote with their own work; henceforth all drivers I write will be available only as modules. - Jukka.
Re: CVS commit: src/sys/arch/i386/conf
On Tue, Aug 09, 2011 at 10:47:18AM +0300, Jukka Ruohonen wrote: On Tue, Aug 09, 2011 at 09:44:09AM +0200, Alan Barrett wrote: Whether or not available as a module is a good reason for removing something from GENERIC is a separate topic which I will not consider in this message. Fortunately, people can vote with their own work; henceforth all drivers I write will be available only as modules. You mean, your work cannot be inclued in non-modular kernels ? this is silly. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/sys/arch/i386/conf
On Tue, Aug 09, 2011 at 11:16:11AM +0300, Jukka Ruohonen wrote: On Tue, Aug 09, 2011 at 10:14:08AM +0200, Manuel Bouyer wrote: On Tue, Aug 09, 2011 at 10:47:18AM +0300, Jukka Ruohonen wrote: On Tue, Aug 09, 2011 at 09:44:09AM +0200, Alan Barrett wrote: Whether or not available as a module is a good reason for removing something from GENERIC is a separate topic which I will not consider in this message. Fortunately, people can vote with their own work; henceforth all drivers I write will be available only as modules. You mean, your work cannot be inclued in non-modular kernels ? Yes. Sorry, but this is just plain stupid. I could as well make so my work won't work in a modular kernel, and we'll have incompatible features. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/sys/arch/i386/conf
On Tue, Aug 09, 2011 at 10:18:29AM +0200, Manuel Bouyer wrote: Sorry, but this is just plain stupid. I could as well make so my work won't work in a modular kernel, and we'll have incompatible features. Of course it will work in non-modular kernels, but you just have to add it there manually. - Jukka.
Re: CVS commit: src/sys/arch/i386/conf
On Tue, Aug 09, 2011 at 11:23:57AM +0300, Jukka Ruohonen wrote: On Tue, Aug 09, 2011 at 10:18:29AM +0200, Manuel Bouyer wrote: Sorry, but this is just plain stupid. I could as well make so my work won't work in a modular kernel, and we'll have incompatible features. Of course it will work in non-modular kernels, but you just have to add it there manually. good, but still, for x86 it should be in MONOLITHIC and ALL. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/sys/arch/i386/conf
On Tue, Aug 09, 2011 at 10:14:08AM +0200, Manuel Bouyer wrote: On Tue, Aug 09, 2011 at 10:47:18AM +0300, Jukka Ruohonen wrote: On Tue, Aug 09, 2011 at 09:44:09AM +0200, Alan Barrett wrote: Whether or not available as a module is a good reason for removing something from GENERIC is a separate topic which I will not consider in this message. Fortunately, people can vote with their own work; henceforth all drivers I write will be available only as modules. You mean, your work cannot be inclued in non-modular kernels ? this is silly. I must find some round tuits and change the kernel config/build to build modules then link the required ones into a partially linked kernel with 'ld -r' before doing a final link to a fully fixed up kernel. This should also make it possible for a user to include an extra module. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/sys/arch/i386/conf
On Thu, Aug 04, 2011 at 02:45:54PM +, Jonathan A. Kollasch wrote: Module Name: src Committed By: jakllsch Date: Thu Aug 4 14:45:54 UTC 2011 Modified Files: src/sys/arch/i386/conf: ALL Log Message: Add coram(4). Can we get manual pages for these? - Jukka.
Re: CVS commit: src/sys/arch/i386/conf
On Wed, 23 Feb 2011 12:17:43 +0900, Masao Uebayashi uebay...@tombi.co.jp wrote: IMHO, for x86, the kernel cannot assume that the bootloader loaded certain modules, nor can the bootloader expect that kernel XYZ is in a specific configuration. They should be agnostic from one another. I think that TRT here is that kernel tells bootloader what to load. This should be possible by allocating a static buffer shared by bootloader/kernel, and kernel does reboot (== calling bootloader). There are, at least, two non trivial points to solve here: - as said, for x86, you are pushing for an interface that does not yet exist between kernel and bootloader. I highly doubt that Grub/Grub2, syslinux, or any other bootloader not under direct control of TNF, will follow such a model. - you have to configure, but also to unconfigure device upon each reboot. You have to teach the interface not only what to load, but also, what is the state of a driver module. Module's loading can change the state of devices, and rebooting/calling bootloader will _not_ reset that state. -- Jean-Yves Migeon jeanyves.mig...@free.fr
Re: CVS commit: src/sys/arch/i386/conf
On Sun, Feb 13, 2011 at 04:29:25PM +0100, Jean-Yves Migeon wrote: On 13.02.2011 14:42, David Laight wrote: On Sun, Feb 13, 2011 at 04:37:21AM +, Jean-Yves Migeon wrote: Module Name: src Committed By: jym Date: Sun Feb 13 04:37:21 UTC 2011 Modified Files: src/sys/arch/i386/conf: GENERIC Log Message: Compile FFS and NFS statically (e.g. not modular) for GENERIC. These file-systems can be critical for mountroot; as kernel cannot have access to module(7)s without having / mounted first... yes, you see the point. Does this cause grief with existing installations where the bootloader also loads these as modules? No; if it does, it should not: the bootloader is free to load whatever modules it wants to, and this happens also when the user specifies it to load certain modules manually. It could print errors messages (although, in my tests, it did not), but should not hamper boot in any way. IMHO, for x86, the kernel cannot assume that the bootloader loaded certain modules, nor can the bootloader expect that kernel XYZ is in a specific configuration. They should be agnostic from one another. I think that TRT here is that kernel tells bootloader what to load. This should be possible by allocating a static buffer shared by bootloader/kernel, and kernel does reboot (== calling bootloader). bootloader load modules in the boot module list (initially nothing) kernel while (configure devices) if (module A not found) append A to the boot module list (static buffer) reboot mountroot : The reason why this reboots the system repeatedly is that the kernel has no knowledge of the exact hardware/mount configuration. In other words, the boot is non-deterministic. The opposite case is static kernel configuration, typically embedded platforms where hardware configuration is static. In such a case, you can configure kernel exactly for the specification. The kernel always boots in the same manner. I.e. it is deterministic. Besides, that would be problematic if it were not the case: given that boot(8) can auto-load ffs or nfs kmods, the bootloader would be bound with modular kernels. For order of preference, see module(7): The loader will look first for a built-in module with the specified name that has not been disabled (see module_unload() below). If a built-in module with that name is not found, the list of modules prepared by the boot loader is searched. If the named module is still not found, an attempt is made to locate the module within the file system. -- Jean-Yves Migeon jeanyves.mig...@free.fr -- Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
Re: CVS commit: src/sys/arch/i386/conf
On Sun, Feb 13, 2011 at 04:37:21AM +, Jean-Yves Migeon wrote: Module Name: src Committed By: jym Date: Sun Feb 13 04:37:21 UTC 2011 Modified Files: src/sys/arch/i386/conf: GENERIC Log Message: Compile FFS and NFS statically (e.g. not modular) for GENERIC. These file-systems can be critical for mountroot; as kernel cannot have access to module(7)s without having / mounted first... yes, you see the point. Does this cause grief with existing installations where the bootloader also loads these as modules? David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/sys/arch/i386/conf
On 13.02.2011 14:42, David Laight wrote: On Sun, Feb 13, 2011 at 04:37:21AM +, Jean-Yves Migeon wrote: Module Name: src Committed By: jym Date: Sun Feb 13 04:37:21 UTC 2011 Modified Files: src/sys/arch/i386/conf: GENERIC Log Message: Compile FFS and NFS statically (e.g. not modular) for GENERIC. These file-systems can be critical for mountroot; as kernel cannot have access to module(7)s without having / mounted first... yes, you see the point. Does this cause grief with existing installations where the bootloader also loads these as modules? No; if it does, it should not: the bootloader is free to load whatever modules it wants to, and this happens also when the user specifies it to load certain modules manually. It could print errors messages (although, in my tests, it did not), but should not hamper boot in any way. IMHO, for x86, the kernel cannot assume that the bootloader loaded certain modules, nor can the bootloader expect that kernel XYZ is in a specific configuration. They should be agnostic from one another. Besides, that would be problematic if it were not the case: given that boot(8) can auto-load ffs or nfs kmods, the bootloader would be bound with modular kernels. For order of preference, see module(7): The loader will look first for a built-in module with the specified name that has not been disabled (see module_unload() below). If a built-in module with that name is not found, the list of modules prepared by the boot loader is searched. If the named module is still not found, an attempt is made to locate the module within the file system. -- Jean-Yves Migeon jeanyves.mig...@free.fr
Re: CVS commit: src/sys/arch/i386/conf
On Sun, 13 Feb 2011, Jean-Yves Migeon wrote: ... For order of preference, see module(7): The loader will look first for a built-in module with the specified name that has not been disabled (see module_unload() below). If a built-in module with that name is not found, the list of modules prepared by the boot loader is searched. If the named module is still not found, an attempt is made to locate the module within the file system. There should be one additional qualification here. Searching for modules within the file system can only occur after the root file system has been mounted by the initialization code. - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: CVS commit: src/sys/arch/i386/conf
On 13.02.2011 17:02, Paul Goyette wrote: On Sun, 13 Feb 2011, Jean-Yves Migeon wrote: ... For order of preference, see module(7): The loader will look first for a built-in module with the specified name that has not been disabled (see module_unload() below). If a built-in module with that name is not found, the list of modules prepared by the boot loader is searched. If the named module is still not found, an attempt is made to locate the module within the file system. There should be one additional qualification here. Searching for modules within the file system can only occur after the root file system has been mounted by the initialization code. Sorry, this part is from module(9). For module(7), there is a mention in the CAVEATS section: If an attempt is made to boot the operating system from a file system for which the module is not built into the kernel, the boot may fail with the message ``Cannot mount root, error 79''. On certain architectures (currently, i386 and amd64), one may be able to recover from this error by using the ``load xxxfs'' command before trying to boot. This command is only available on newer bootloaders. Wording seems a bit redundant, so I condensed this into: Index: man/man9/module.9 === RCS file: /cvsroot/src/share/man/man9/module.9,v retrieving revision 1.26 diff -u -p -u -p -r1.26 module.9 --- man/man9/module.9 9 Jan 2011 05:05:10 - 1.26 +++ man/man9/module.9 13 Feb 2011 16:39:01 - @@ -175,7 +175,8 @@ If a built-in module with that .Fa name is not found, the list of modules prepared by the boot loader is searched. If the named module is still not found, an attempt is made to locate the -module within the file system. +module within the file system, provided it has been mounted by the +initialization code. .Pp The .Fa flags -- Jean-Yves Migeon jeanyves.mig...@free.fr
Re: CVS commit: src/sys/arch/i386/conf
On Fri, Feb 11, 2011 at 06:30:17AM +, Matthias Scheler wrote: EXEC_ELF32, _SCRIPT # obvious FFS, CD9660, MFS, TMPFS, NFS, EXT2FS FFS should be compiled into the kernel. But I doubt that somebody uses both MFS and TMPFS. I hardly ever use CD9660 or EXT2FS while I use NFS a lot. There will however be people with is opposite requirements which is why those should really be modules. None of these are large enough that it matters to compile them in if you aren't using them. (Unless you're using a 486 or something in which case you probably need a custom small kernel anyway.) -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/arch/i386/conf
both MFS and TMPFS. I hardly ever use CD9660 or EXT2FS while I use NFS a lot. There will however be people with is opposite requirements which is why those should really be modules. For install, root on CD9660 is possible. (though we can put cd9660.kmod into the cd9660fs) e.g. the typical file-systems we may have to use, without having to rely on modules that could be absent or non accessible at boot time. I don't think it needs typical file-systems. IMHO the kernel should contain the file-systems required for booting. Not booting, but mountroot. I.e. even EXEC_ELF32/EXEC_SCRIPT and MFS/TMPFS can be loaded after mountroot. Typical file-systems should be compiled in kernel for floppies and tapes (or lazy users who don't bother to put module files into root file system) but not for CD and USB images because we can put module files into them. NFS might be problematic because it isn't clear if all pxeboot (or other bootloaders) can simply load nfs.kmod via network. --- Izumi Tsutsui
Re: CVS commit: src/sys/arch/i386/conf
On 11.02.2011 07:30, Matthias Scheler wrote: On Fri, Feb 11, 2011 at 05:06:43AM +0100, Jean-Yves Migeon wrote: Indeed, it would be good to have at least some exec formats and file-systems builtin by default in GENERIC: EXEC_ELF32, _SCRIPT # obvious FFS, CD9660, MFS, TMPFS, NFS, EXT2FS FFS should be compiled into the kernel. But I doubt that somebody uses both MFS and TMPFS. I hardly ever use CD9660 or EXT2FS while I use NFS a lot. There will however be people with is opposite requirements which is why those should really be modules. e.g. the typical file-systems we may have to use, without having to rely on modules that could be absent or non accessible at boot time. I don't think it needs typical file-systems. IMHO the kernel should contain the file-systems required for booting. This will solve most of the update issues. This will allow booting, but not necessarily in a sufficient environment to fix update issues: if someone needs to mount an ISO or NFS share to get updated modules, he will need these. Besides, it's more or less the list of file-systems that have associated mount_* in the INSTALL ramdisk; I removed some though: ntfs, kernfs, lfs and msdos. -- Jean-Yves Migeon jeanyves.mig...@free.fr
Re: CVS commit: src/sys/arch/i386/conf
On Fri, Feb 11, 2011 at 12:40:00AM +0100, Jean-Yves Migeon wrote: BTW, I wonder whether modules shouldn't be part of the kern-GENERIC.tgz set. But this is an orthogonal issue. As is building the modules as part of the kernel build, and having the kernel build include a kernel.o stage into which module.o can be linked so build a custom kernel with a list of builtin module. I might look into this when I get by systems accessible again (should be soon). David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/sys/arch/i386/conf
On Thu, Feb 10, 2011 at 04:49:19PM +, Jean-Yves Migeon wrote: Module Name: src Committed By: jym Date: Thu Feb 10 16:49:19 UTC 2011 Modified Files: src/sys/arch/i386/conf: INSTALL Log Message: For i386, include MONOLITHIC for INSTALL rather than GENERIC. While here, remove drm drivers, we don't need them for install. i386 GENERIC has FFS and ELF support compiled as modules, so we hit an interesting chicken-egg situation when the kernel attempts to mount a ffs ramdisk, while the module might be contained inside... the ramdisk. I'm not 100% sure it is worth having FFS and ELF support as modules in GENERIC. It may be nice that they CAN be modules, but I suspect 99.99% of systems will need them. Anyone who wants them as modules can build a kernel without them. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/sys/arch/i386/conf
On 10.02.2011 22:23, David Laight wrote: On Thu, Feb 10, 2011 at 04:49:19PM +, Jean-Yves Migeon wrote: Module Name: src Committed By:jym Date:Thu Feb 10 16:49:19 UTC 2011 Modified Files: src/sys/arch/i386/conf: INSTALL Log Message: For i386, include MONOLITHIC for INSTALL rather than GENERIC. While here, remove drm drivers, we don't need them for install. i386 GENERIC has FFS and ELF support compiled as modules, so we hit an interesting chicken-egg situation when the kernel attempts to mount a ffs ramdisk, while the module might be contained inside... the ramdisk. I'm not 100% sure it is worth having FFS and ELF support as modules in GENERIC. It may be nice that they CAN be modules, but I suspect 99.99% of systems will need them. Anyone who wants them as modules can build a kernel without them. It's something I mentioned privately with Jared. I think we could come up with a golden mean for GENERIC kernels: leave most third party drivers/systems as modules, while keeping critical ones included by default. FFS and ELF come to mind, but there are others too. amd64 GENERIC is close to this. This would open up the possibility to provide a modular kernel, without going the all or nothing MONOLITHIC way (and avoid many complaints like I just replaced my kernel for testing, and it returns an error when attempting to mount / or exec init). BTW, I wonder whether modules shouldn't be part of the kern-GENERIC.tgz set. But this is an orthogonal issue. -- Jean-Yves Migeon jeanyves.mig...@free.fr
re: CVS commit: src/sys/arch/i386/conf
Module Name:src Committed By: jym Date: Thu Feb 10 16:49:19 UTC 2011 Modified Files: src/sys/arch/i386/conf: INSTALL Log Message: For i386, include MONOLITHIC for INSTALL rather than GENERIC. While here, remove drm drivers, we don't need them for install. i386 GENERIC has FFS and ELF support compiled as modules, so we hit an interesting chicken-egg situation when the kernel attempts to mount a ffs ramdisk, while the module might be contained inside... the ramdisk. I'm not 100% sure it is worth having FFS and ELF support as modules in GENERIC. It may be nice that they CAN be modules, but I suspect 99.99% of systems will need them. Anyone who wants them as modules can build a kernel without them. i strongly agree with this.
re: CVS commit: src/sys/arch/i386/conf
On Fri, 11 Feb 2011, matthew green wrote: Module Name:src Committed By: jym Date: Thu Feb 10 16:49:19 UTC 2011 Modified Files: src/sys/arch/i386/conf: INSTALL Log Message: For i386, include MONOLITHIC for INSTALL rather than GENERIC. While here, remove drm drivers, we don't need them for install. i386 GENERIC has FFS and ELF support compiled as modules, so we hit an interesting chicken-egg situation when the kernel attempts to mount a ffs ramdisk, while the module might be contained inside... the ramdisk. I'm not 100% sure it is worth having FFS and ELF support as modules in GENERIC. It may be nice that they CAN be modules, but I suspect 99.99% of systems will need them. Anyone who wants them as modules can build a kernel without them. i strongly agree with this. Me too. My totally modular kernel config file contains ... no options EXEC_ELF64 no options EXEC_SCRIPT no options COREDUMP no options AIO no options MQUEUE ... Not hard to type, not hard to maintain. - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: CVS commit: src/sys/arch/i386/conf
On Sun, Aug 08, 2010 at 08:04:54PM +, Chuck Silvers wrote: [...] @@ -740,6 +740,10 @@ spdmem* at iic? addr 0x51 spdmem* at iic? addr 0x52 spdmem* at iic? addr 0x53 +spdmem* at iic? addr 0x54 +spdmem* at iic? addr 0x55 +spdmem* at iic? addr 0x56 +spdmem* at iic? addr 0x57 sdtemp* at iic? addr 0x18 You know, having more than one instance of any given attachment of a device in ALL is actually pointless: it doesn't change what gets compiled, and ALL is only a way to test compilation of as much of the kernel as possible. Not that it hurts in any way; it just doesn't change anything. (The se part of your commit was, of course, not pointless at all!) -- Quentin Garnier - c...@cubidou.net - c...@netbsd.org See the look on my face from staying too long in one place [...] every time the morning breaks I know I'm closer to falling KT Tunstall, Saving My Face, Drastic Fantastic, 2007. pgpDSs1DLvt2D.pgp Description: PGP signature
Re: CVS commit: src/sys/arch/i386/conf
On Wed, Aug 26, 2009 at 12:01:39AM -0400, Elad Efrat wrote: Log Message: Build NiLFS(2). (2)? :-p That's how it's written in the configuration file... That seems... odd. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/arch/i386/conf
On Wed, Aug 26, 2009 at 03:39:16AM +, Elad Efrat wrote: Log Message: Build NiLFS(2). (2)? :-p -- David A. Holland dholl...@netbsd.org
