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/share/misc
Jukka Ruohonen jruoho-s783fymb3ccdnm+yrof...@public.gmane.org writes: Module Name: src Committed By: jruoho Date: Thu Feb 10 17:52:18 UTC 2011 Modified Files: src/share/misc: acronyms.comp Log Message: ACID, BFS, CIL, DBMS, DFA, FSM, GPS, LLVM, MCC, ML, NFA, NP, NTM, OOSE, OTS, PDA, RSS, RUP, SDL, SDT, TECO, TM, TP, UCS, XOR. To generate a diff of this commit: cvs rdiff -u -r1.116 -r1.117 src/share/misc/acronyms.comp Index: src/share/misc/acronyms.comp diff -u src/share/misc/acronyms.comp:1.116 src/share/misc/acronyms.comp:1.117 --- src/share/misc/acronyms.comp:1.116Mon Jan 17 22:08:30 2011 +++ src/share/misc/acronyms.comp Thu Feb 10 17:52:18 2011 @@ -373,6 +380,7 @@ MBR master boot record MC memory controller MCA machine check architecture +MCC multiversion concurrency control MCE machine check exception MCGA multicolor graphics adapter MCH memory controller hub Isn't it called MVCC usually? Multiple version concurrency control. Honestly, it's the first time I see this abbreviation for MVCC. -- HE CE3OH...
