Re: CVS commit: src/sys/arch/amd64/conf
On 2/19/2011 8:13 AM, Matthias Drochner wrote: I think before modular kernels are forced onto the masses, at least 2 design problems should be fixed: 1. Autoloading needs to be done differently: The kernel doesn't have the smarts to know which module is needed in which situation, and there is no fine-grained administrative control. I've complained in some other mail about the idiotic behavior in case of exec format loaders. Do you mean (for example) a more direct relationship between the kernel and the modules of the same vintage? (My major issue with modules is that a "non-essential, but used" module that is installed in an otherwise working system is a PITA to revert...boot with modules disabled, find the manually-backed-up version of the broken module, restore it, then reboot again...and cross your fingers there are no unforeseen inter-dependencies). If that's not what you mean, can you elaborate?
Re: CVS commit: src/lib/librumphijack
On Sat, Feb 19, 2011 at 07:54:25PM +0200, Antti Kantee wrote: > On Sat Feb 19 2011 at 14:58:45 +0100, Joerg Sonnenberger wrote: > > On Sat, Feb 19, 2011 at 01:10:36PM +, Antti Kantee wrote: > > > Module Name: src > > > Committed By: pooka > > > Date: Sat Feb 19 13:10:35 UTC 2011 > > > > > > Modified Files: > > > src/lib/librumphijack: hijack.c > > > > > > Log Message: > > > hijack __getcwd() > > > > Why? > > to make it work To make *what* work. What is using __getcwd directly and not the frontends. If this is yet another hack to deal with SSP, please apply the patch I send to tech-userlevel and test with that first. Joerg
Re: CVS commit: src/sys
On Feb 19, 2011, at 2:05 PM, Mindaugas Rasiukevicius wrote: > David Laight wrote: >> On Sat, Feb 19, 2011 at 08:19:54PM +, Matt Thomas wrote: >>> >>> Log Message: >>> Default PCU_UNIT_COUNT to 0. If 0, don't compile the contents of >>> subr_pcu.c and don't include the pcu related members into struct lwp. >> >> Making a structure layout depend on an option is probably not a good idea! >> At least not unless the structure ends with a series of 'optional' >> sub-stuctures that are found by access functions (which may be >> #defines for things built into the kernel itself). > > Right. I have asked Matt to not #ifdef in struct lwp as well. It already is dependent on a option (PCU_UNIT_COUNT). This just makes it explicit. It doesn't really change anything. MD code needs to define PCU_UNIT_COUNT for its needs.
Re: CVS commit: src/sys
David Laight wrote: > On Sat, Feb 19, 2011 at 08:19:54PM +, Matt Thomas wrote: > > > > Log Message: > > Default PCU_UNIT_COUNT to 0. If 0, don't compile the contents of > > subr_pcu.c and don't include the pcu related members into struct lwp. > > Making a structure layout depend on an option is probably not a good idea! > At least not unless the structure ends with a series of 'optional' > sub-stuctures that are found by access functions (which may be > #defines for things built into the kernel itself). Right. I have asked Matt to not #ifdef in struct lwp as well. -- Mindaugas
Re: CVS commit: src/sys
On Sat, Feb 19, 2011 at 08:19:54PM +, Matt Thomas wrote: > > Log Message: > Default PCU_UNIT_COUNT to 0. If 0, don't compile the contents of subr_pcu.c > and don't include the pcu related members into struct lwp. Making a structure layout depend on an option is probably not a good idea! At least not unless the structure ends with a series of 'optional' sub-stuctures that are found by access functions (which may be #defines for things built into the kernel itself). David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/sys/arch
On Sat, Feb 19, 2011 at 01:52:29PM +, Jared D. McNeill wrote: > Log Message: > modularize VIA PadLock support > - retire options VIA_PADLOCK, replace with 'padlock0 at cpu0' > - driver supports attach & detach > - support building as a module Nice! Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 344-0444 x24
Re: CVS commit: src/lib/librumphijack
On Sat Feb 19 2011 at 14:58:45 +0100, Joerg Sonnenberger wrote: > On Sat, Feb 19, 2011 at 01:10:36PM +, Antti Kantee wrote: > > Module Name:src > > Committed By: pooka > > Date: Sat Feb 19 13:10:35 UTC 2011 > > > > Modified Files: > > src/lib/librumphijack: hijack.c > > > > Log Message: > > hijack __getcwd() > > Why? to make it work -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/sys/arch/amd64/conf
On 19.02.2011 17:13, Matthias Drochner wrote: > > jeanyves.mig...@free.fr said: >> I can't see why MONOLITHIC is needed in the first place > > I think before modular kernels are forced onto the masses, > at least 2 design problems should be fixed: > 1. Autoloading needs to be done differently: The kernel doesn't >have the smarts to know which module is needed in which situation, >and there is no fine-grained administrative control. I've >complained in some other mail about the idiotic behavior >in case of exec format loaders. > 2. I don't want tons of modules which I'll never need installed >into my root file system. As it was common in good old times (tm), >my root filesystems are as small as possible. Now, with modules >being added to the build, I have to squeeze out stuff after >each update to keep some percent free space in /. 1. modules can be turned into builtins, and so you will end up in the same situation as MONOLITHIC, without sacrificing MODULAR. You can preserve monolithic behavior, but still load modules if you want to. 2. issue is the same as with monolithic-like kernels: instead of having code provided as third party files, code is directly embedded in. So what you are gaining as space in one place, you are losing it in another. Smaller file-system, bigger kernel, or the other way around. Granted, kernel does not necessarily reside under / . As said, it's all a matter of choice (which I cannot make). i386 GENERIC was a PITA as all options(4) were modules, thereby affecting boot at the smallest occasion. MONOLITHIC was brought back. On the contrary, amd64 GENERIC was monolithic in nature (most modules are builtins), mimicking i386 MONOLITHIC (but still having modules as possibility), and that did not seem to bother people. So either way, it's fine; but please -- i386 and amd64 should share common grounds. If some want a MONOLITHIC amd64, it's even possible, although I can't see the point given the arguments above. That would also save us a kernel build for i386 release. -- Jean-Yves Migeon jeanyves.mig...@free.fr
Re: CVS commit: src/sys/arch/amd64/conf
jruoho...@iki.fi said: > Have you measured how much modules supposedly increase the size > compared to compiling things directly to the kernel? This seems like a > rather silly point to me (without numbers, at least). The difference is that I can control what is built into my kernel, but I can't control what modules are installed. best regards Matthias Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt
Re: CVS commit: src/sys/arch/amd64/conf
On Sat, Feb 19, 2011 at 05:13:58PM +0100, Matthias Drochner wrote: > 2. I don't want tons of modules which I'll never need installed >into my root file system. As it was common in good old times (tm), >my root filesystems are as small as possible. Now, with modules >being added to the build, I have to squeeze out stuff after >each update to keep some percent free space in /. Have you measured how much modules supposedly increase the size compared to compiling things directly to the kernel? This seems like a rather silly point to me (without numbers, at least). - Jukka.
Re: CVS commit: src/sys/arch/amd64/conf
jeanyves.mig...@free.fr said: > I can't see why MONOLITHIC is needed in the first place I think before modular kernels are forced onto the masses, at least 2 design problems should be fixed: 1. Autoloading needs to be done differently: The kernel doesn't have the smarts to know which module is needed in which situation, and there is no fine-grained administrative control. I've complained in some other mail about the idiotic behavior in case of exec format loaders. 2. I don't want tons of modules which I'll never need installed into my root file system. As it was common in good old times (tm), my root filesystems are as small as possible. Now, with modules being added to the build, I have to squeeze out stuff after each update to keep some percent free space in /. best regards Matthias Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt
Re: CVS commit: src/sys/arch/amd64/conf
On 19.02.2011 10:27, Bernd Ernesti wrote: > On Wed, Feb 16, 2011 at 03:16:58AM +, Jean-Yves Migeon wrote: >> Module Name: src >> Committed By:jym >> Date:Wed Feb 16 03:16:58 UTC 2011 >> >> Modified Files: >> src/sys/arch/amd64/conf: GENERIC INSTALL >> >> Log Message: >> Build certain file-systems and options(7) as module(7). 32 and 64 bits >> support are still builtin, as well as FFS, NFS, TMPFS, and most COMPAT >> code. Saves approx. 750kiB. >> >> Reflect this in INSTALL kernel, where we have to support more file systems >> statically. >> >> See http://mail-index.netbsd.org/port-amd64/2011/02/13/msg001318.html > > Are you going to add a MONOLITHIC kernel to match i386? No. And honestly, I can't see why MONOLITHIC is needed in the first place: it was introduced as a quick fix for those that wanted to bluntly replace their old kernel with a new one, without risking crippling their system on reboot because ELF and FFS kmods were gone missing. I dare say that MONOLITHIC was a step in the wrong direction: instead of cutting down MODULAR options(4) from GENERIC, it would have been better to include everything as builtin modules, while still offering modular support. I can't see the difference of having MONOLITHIC instead of GENERIC with modules as builtins, except for cases where you want to block module loading, for security purposes. But there, you are better off removing most COMPAT code also, which means a new kernel build, anyway. I perfectly know that the question of "what should be in, and what should stay as a third party kmod?" is entirely debatable. I notified core@ about that, and wait for their answer. We could have the bare minimum builtin inside GENERIC, or provide most options(7) as kmods by default. -- Jean-Yves Migeon jeanyves.mig...@free.fr
Re: CVS commit: src/sys/arch
Any chance we get a padlock(4) man page for this? :) On Sat, 19 Feb 2011, Jared D. McNeill wrote: Module Name:src Committed By: jmcneill Date: Sat Feb 19 13:52:29 UTC 2011 Modified Files: src/sys/arch/i386/conf: ALL GENERIC src/sys/arch/i386/i386: autoconf.c src/sys/arch/x86/conf: files.x86 src/sys/arch/x86/include: cpu.h cpuvar.h via_padlock.h src/sys/arch/x86/x86: cpu.c identcpu.c via_padlock.c Log Message: modularize VIA PadLock support - retire options VIA_PADLOCK, replace with 'padlock0 at cpu0' - driver supports attach & detach - support building as a module To generate a diff of this commit: cvs rdiff -u -r1.288 -r1.289 src/sys/arch/i386/conf/ALL cvs rdiff -u -r1.1017 -r1.1018 src/sys/arch/i386/conf/GENERIC cvs rdiff -u -r1.95 -r1.96 src/sys/arch/i386/i386/autoconf.c cvs rdiff -u -r1.57 -r1.58 src/sys/arch/x86/conf/files.x86 cvs rdiff -u -r1.26 -r1.27 src/sys/arch/x86/include/cpu.h cvs rdiff -u -r1.38 -r1.39 src/sys/arch/x86/include/cpuvar.h cvs rdiff -u -r1.5 -r1.6 src/sys/arch/x86/include/via_padlock.h cvs rdiff -u -r1.80 -r1.81 src/sys/arch/x86/x86/cpu.c cvs rdiff -u -r1.22 -r1.23 src/sys/arch/x86/x86/identcpu.c cvs rdiff -u -r1.13 -r1.14 src/sys/arch/x86/x86/via_padlock.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. !DSPAM:4d5fcb2a2279290418422! - | 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/lib/librumphijack
On Sat, Feb 19, 2011 at 01:10:36PM +, Antti Kantee wrote: > Module Name: src > Committed By: pooka > Date: Sat Feb 19 13:10:35 UTC 2011 > > Modified Files: > src/lib/librumphijack: hijack.c > > Log Message: > hijack __getcwd() Why? Joerg
Re: CVS commit: src/sys/arch/amd64/conf
On Feb,Saturday 19 2011, at 11:27 AM, Bernd Ernesti wrote: > On Wed, Feb 16, 2011 at 03:16:58AM +, Jean-Yves Migeon wrote: >> Module Name: src >> Committed By:jym >> Date:Wed Feb 16 03:16:58 UTC 2011 >> >> Modified Files: >> src/sys/arch/amd64/conf: GENERIC INSTALL >> >> Log Message: >> Build certain file-systems and options(7) as module(7). 32 and 64 bits >> support are still builtin, as well as FFS, NFS, TMPFS, and most COMPAT >> code. Saves approx. 750kiB. >> >> Reflect this in INSTALL kernel, where we have to support more file systems >> statically. >> >> See http://mail-index.netbsd.org/port-amd64/2011/02/13/msg001318.html > > Are you going to add a MONOLITHIC kernel to match i386? I object against such change so I hope that we are not going to repeat such move. Regards Adam.
Re: CVS commit: src/sys/arch/amd64/conf
On Wed, Feb 16, 2011 at 03:16:58AM +, Jean-Yves Migeon wrote: > Module Name: src > Committed By: jym > Date: Wed Feb 16 03:16:58 UTC 2011 > > Modified Files: > src/sys/arch/amd64/conf: GENERIC INSTALL > > Log Message: > Build certain file-systems and options(7) as module(7). 32 and 64 bits > support are still builtin, as well as FFS, NFS, TMPFS, and most COMPAT > code. Saves approx. 750kiB. > > Reflect this in INSTALL kernel, where we have to support more file systems > statically. > > See http://mail-index.netbsd.org/port-amd64/2011/02/13/msg001318.html Are you going to add a MONOLITHIC kernel to match i386? Bernd
