Re: CVS commit: src/sys/arch/amd64/conf
matthew green writes: > could this be done with include and "no foo" statement? > eg, like sys/arch/sparc/conf/INSTALL does. Maybe, but I'm not sure it will end up working. Right now we don't know if any of the missing things will be trouble, and even if we do move to include/no I'd like to do that via an intermediate step of a config with small differences. Also I think we should also consider extracting lots of things into includable files, similar to how include "dev/usb/usbdevices.config" is used now in GENERIC. That will raise interesting cross-arch issues about value vs kernel memory usage probably. These include files would allow a simplification of XEN3_DOMU which as I see it should have ~no drivers but all the rest of the options. signature.asc Description: PGP signature
re: CVS commit: src/sys/arch/amd64/conf
"Greg Troxel" writes: > Module Name: src > Committed By: gdt > Date: Fri Mar 5 20:30:56 UTC 2021 > > Modified Files: > src/sys/arch/amd64/conf: XEN3_DOM0 > > Log Message: > XEN3_DOM0: Approach GENERIC > > When processed to remove comments, blank lines, normalize whitespace, > and sort/uniq (one line was previously duplicated), this file is > identical to the previous version. It has been reorganized to reduce > diffs to GENERIC, and many missing lines from GENERIC have been added > but commented out. could this be done with include and "no foo" statement? eg, like sys/arch/sparc/conf/INSTALL does. .mrg.
Re: CVS commit: src/sys/arch/amd64/conf
On 07.08.2019 08:28, Maxime Villard wrote: > Module Name: src > Committed By: maxv > Date: Wed Aug 7 06:28:03 UTC 2019 > > Modified Files: > src/sys/arch/amd64/conf: GENERIC > > Log Message: > Sync with reality. > > Can we enable USER_LDT by default in GENERIC? > To generate a diff of this commit: > cvs rdiff -u -r1.532 -r1.533 src/sys/arch/amd64/conf/GENERIC > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > > > Modified files: > > Index: src/sys/arch/amd64/conf/GENERIC > diff -u src/sys/arch/amd64/conf/GENERIC:1.532 > src/sys/arch/amd64/conf/GENERIC:1.533 > --- src/sys/arch/amd64/conf/GENERIC:1.532 Thu Aug 1 13:48:50 2019 > +++ src/sys/arch/amd64/conf/GENERIC Wed Aug 7 06:28:03 2019 > @@ -1,4 +1,4 @@ > -# $NetBSD: GENERIC,v 1.532 2019/08/01 13:48:50 msaitoh Exp $ > +# $NetBSD: GENERIC,v 1.533 2019/08/07 06:28:03 maxv Exp $ > # > # GENERIC machine description file > # > @@ -22,7 +22,7 @@ include "arch/amd64/conf/std.amd64" > > options INCLUDE_CONFIG_FILE # embed config file in kernel binary > > -#ident "GENERIC-$Revision: 1.532 $" > +#ident "GENERIC-$Revision: 1.533 $" > > maxusers 64 # estimated number of users > > @@ -74,15 +74,12 @@ options USERCONF# userconf(4) support > 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 > makeoptions SPECTRE_V2_GCC_MITIGATION=1 # GCC Spectre variant 2 > # migitation > options SPECTRE_V2_GCC_MITIGATION > > -# USER_LDT. You need to disable SVS to use it. > -#options USER_LDT# user-settable LDT; used by WINE > -#no options SVS > - > # CPU features > acpicpu* at cpu? # ACPI CPU (including frequency scaling) > coretemp*at cpu? # Intel on-die thermal sensor > signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/sys/arch/amd64/conf
On Tue, Mar 13, 2018 at 06:02:54PM +0100, Maxime Villard wrote: > Le 11/03/2018 à 22:30, Joerg Sonnenberger a écrit : > > Haswell, using VTx. It seems to hit a triple fault in db_panic according > > to the vbox.log. > > At which stage of the boot procedure does it happen? Does it happen right > before init is launched? Or does the kernel fault right after the bootloader? Right after the boot loader. Joerg
Re: CVS commit: src/sys/arch/amd64/conf
Le 11/03/2018 à 22:30, Joerg Sonnenberger a écrit : On Sat, Mar 10, 2018 at 06:58:39PM +0100, Maxime Villard wrote: Le 09/03/2018 à 20:33, Joerg Sonnenberger a écrit : On Fri, Mar 09, 2018 at 06:36:45PM +0100, Maxime Villard wrote: Le 09/03/2018 à 18:14, Joerg Sonnenberger a écrit : On Mon, Feb 26, 2018 at 05:52:50AM +, Maxime Villard wrote: Module Name:src Committed By: maxv Date: Mon Feb 26 05:52:50 UTC 2018 Modified Files: src/sys/arch/amd64/conf: GENERIC Log Message: Enable SVS by default. This broke using VirtualBox and I wouldn't be surprised by other virtualisation solutions to be affected as well. I'm using VirtualBox with SVS enabled, and have been doing this for two months already, everything works fine for me. I get an instant guru meditation once the kernel is loaded and starting. hardware-assisted or not? I use hardware-assisted, 4.x and 5.x. Haswell, using VTx. It seems to hit a triple fault in db_panic according to the vbox.log. At which stage of the boot procedure does it happen? Does it happen right before init is launched? Or does the kernel fault right after the bootloader?
Re: CVS commit: src/sys/arch/amd64/conf
On Sat, Mar 10, 2018 at 06:58:39PM +0100, Maxime Villard wrote: > Le 09/03/2018 à 20:33, Joerg Sonnenberger a écrit : > > On Fri, Mar 09, 2018 at 06:36:45PM +0100, Maxime Villard wrote: > > > Le 09/03/2018 à 18:14, Joerg Sonnenberger a écrit : > > > > On Mon, Feb 26, 2018 at 05:52:50AM +, Maxime Villard wrote: > > > > > Module Name: src > > > > > Committed By: maxv > > > > > Date: Mon Feb 26 05:52:50 UTC 2018 > > > > > > > > > > Modified Files: > > > > > src/sys/arch/amd64/conf: GENERIC > > > > > > > > > > Log Message: > > > > > Enable SVS by default. > > > > > > > > This broke using VirtualBox and I wouldn't be surprised by other > > > > virtualisation solutions to be affected as well. > > > > > > I'm using VirtualBox with SVS enabled, and have been doing this for two > > > months already, everything works fine for me. > > > > I get an instant guru meditation once the kernel is loaded and starting. > > hardware-assisted or not? I use hardware-assisted, 4.x and 5.x. Haswell, using VTx. It seems to hit a triple fault in db_panic according to the vbox.log. Joerg
Re: CVS commit: src/sys/arch/amd64/conf
On Sat, Mar 10, 2018 at 06:58:39PM +0100, Maxime Villard wrote: > hardware-assisted or not? I use hardware-assisted, 4.x and 5.x. I guess also the host CPU will matter (at least in virtualbox). Martin
Re: CVS commit: src/sys/arch/amd64/conf
Le 09/03/2018 à 20:33, Joerg Sonnenberger a écrit : On Fri, Mar 09, 2018 at 06:36:45PM +0100, Maxime Villard wrote: Le 09/03/2018 à 18:14, Joerg Sonnenberger a écrit : On Mon, Feb 26, 2018 at 05:52:50AM +, Maxime Villard wrote: Module Name:src Committed By: maxv Date: Mon Feb 26 05:52:50 UTC 2018 Modified Files: src/sys/arch/amd64/conf: GENERIC Log Message: Enable SVS by default. This broke using VirtualBox and I wouldn't be surprised by other virtualisation solutions to be affected as well. I'm using VirtualBox with SVS enabled, and have been doing this for two months already, everything works fine for me. I get an instant guru meditation once the kernel is loaded and starting. hardware-assisted or not? I use hardware-assisted, 4.x and 5.x.
Re: CVS commit: src/sys/arch/amd64/conf
On Fri, Mar 09, 2018 at 06:36:45PM +0100, Maxime Villard wrote: > Le 09/03/2018 à 18:14, Joerg Sonnenberger a écrit : > > On Mon, Feb 26, 2018 at 05:52:50AM +, Maxime Villard wrote: > > > Module Name: src > > > Committed By: maxv > > > Date: Mon Feb 26 05:52:50 UTC 2018 > > > > > > Modified Files: > > > src/sys/arch/amd64/conf: GENERIC > > > > > > Log Message: > > > Enable SVS by default. > > > > This broke using VirtualBox and I wouldn't be surprised by other > > virtualisation solutions to be affected as well. > > I'm using VirtualBox with SVS enabled, and have been doing this for two > months already, everything works fine for me. I get an instant guru meditation once the kernel is loaded and starting. Joerg
Re: CVS commit: src/sys/arch/amd64/conf
Le 09/03/2018 à 18:36, Maxime Villard a écrit : Le 09/03/2018 à 18:14, Joerg Sonnenberger a écrit : On Mon, Feb 26, 2018 at 05:52:50AM +, Maxime Villard wrote: Module Name:src Committed By:maxv Date:Mon Feb 26 05:52:50 UTC 2018 Modified Files: src/sys/arch/amd64/conf: GENERIC Log Message: Enable SVS by default. This broke using VirtualBox and I wouldn't be surprised by other virtualisation solutions to be affected as well. I'm using VirtualBox with SVS enabled, and have been doing this for two months already, everything works fine for me. and by the way I also booted NetBSD+SVS on Qemu several times with different cpu configurations, everything works fine, there is no problem.
Re: CVS commit: src/sys/arch/amd64/conf
Le 09/03/2018 à 18:14, Joerg Sonnenberger a écrit : On Mon, Feb 26, 2018 at 05:52:50AM +, Maxime Villard wrote: Module Name:src Committed By: maxv Date: Mon Feb 26 05:52:50 UTC 2018 Modified Files: src/sys/arch/amd64/conf: GENERIC Log Message: Enable SVS by default. This broke using VirtualBox and I wouldn't be surprised by other virtualisation solutions to be affected as well. I'm using VirtualBox with SVS enabled, and have been doing this for two months already, everything works fine for me.
Re: CVS commit: src/sys/arch/amd64/conf
On Mon, Feb 26, 2018 at 05:52:50AM +, Maxime Villard wrote: > Module Name: src > Committed By: maxv > Date: Mon Feb 26 05:52:50 UTC 2018 > > Modified Files: > src/sys/arch/amd64/conf: GENERIC > > Log Message: > Enable SVS by default. This broke using VirtualBox and I wouldn't be surprised by other virtualisation solutions to be affected as well. Joerg
Re: CVS commit: src/sys/arch/amd64/conf
On Sat, Dec 02, 2017 at 09:59:02AM +, Maxime Villard wrote: > Module Name: src > Committed By:maxv > Date:Sat Dec 2 09:59:02 UTC 2017 > > Modified Files: > src/sys/arch/amd64/conf: ALL > > Log Message: > Remove options that do not exist on amd64. Compile-testing those is still useful. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/arch/amd64/conf
On 10/20/17 11:08, Manuel Bouyer wrote: On Fri, Oct 20, 2017 at 07:06:18AM -0300, Jared McNeill wrote: On Fri, 20 Oct 2017, Manuel Bouyer wrote: Any reason to not add it to other arches (especially i386) too ? I wasn't sure it would work everywhere because there are structures used to talk to the firmware that are defined (by both the bwfm driver and the firmware) w/o __packed. Are you able to test i386? no, I don't have such device ... WFM - I added it. Nick
Re: CVS commit: src/sys/arch/amd64/conf
On Fri, Oct 20, 2017 at 07:06:18AM -0300, Jared McNeill wrote: > On Fri, 20 Oct 2017, Manuel Bouyer wrote: > > > Any reason to not add it to other arches (especially i386) too ? > > I wasn't sure it would work everywhere because there are structures used to > talk to the firmware that are defined (by both the bwfm driver and the > firmware) w/o __packed. > > Are you able to test i386? no, I don't have such device ... -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/sys/arch/amd64/conf
On Fri, 20 Oct 2017, Manuel Bouyer wrote: Any reason to not add it to other arches (especially i386) too ? I wasn't sure it would work everywhere because there are structures used to talk to the firmware that are defined (by both the bwfm driver and the firmware) w/o __packed. Are you able to test i386?
Re: CVS commit: src/sys/arch/amd64/conf
On Thu, Oct 19, 2017 at 11:59:56PM +, Jared D. McNeill wrote: > Module Name: src > Committed By: jmcneill > Date: Thu Oct 19 23:59:56 UTC 2017 > > Modified Files: > src/sys/arch/amd64/conf: GENERIC > > Log Message: > add bwfm Any reason to not add it to other arches (especially i386) too ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/sys/arch/amd64/conf
See PR kern/51597 There is some rtsock stuff that does not get included in the compat module. On Sat, 19 Aug 2017, co...@sdf.org wrote: try to run 7.1 ifconfig on 8.0. without COMPAT_70 in the kernel, it won't run. Its non-compatibility is probably buried deep within a switch statement for a generic function. The only way we can reasonably make it work is: - lie about what compat is, and build it inot the kernel, which also hurts people who want to remove it because they are using weak archs - make networking modular? - kernel hot patching (runtime cost) We can drop the pretense. it doesn't work. !DSPAM:59979908113027780614962! +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: CVS commit: src/sys/arch/amd64/conf
try to run 7.1 ifconfig on 8.0. without COMPAT_70 in the kernel, it won't run. Its non-compatibility is probably buried deep within a switch statement for a generic function. The only way we can reasonably make it work is: - lie about what compat is, and build it inot the kernel, which also hurts people who want to remove it because they are using weak archs - make networking modular? - kernel hot patching (runtime cost) We can drop the pretense. it doesn't work.
Re: CVS commit: src/sys/arch/amd64/conf
On Wed, Aug 16, 2017 at 05:46:29AM +0800, Paul Goyette wrote: > On Tue, 15 Aug 2017, Martin Husemann wrote: > > > On Tue, Aug 15, 2017 at 04:33:19PM +0200, Maxime Villard wrote: > > > So we agree? Each compat should be independent. > > > > Yes. > > Well, not totally independent! We have module dependencies to enable the > use of common code. Sure, but independend of each other (top level compat modules). The other modules are just implementation details. Btw: if some ifdefs can not be resolved, it would still be good to build the .o files from a common source, and do other ifdef magic in the file including the implementation (similar to what we do with Elf32 vs. Elf64) or just Makefile magic to set the proper ifdefs and output names. Martin
Re: CVS commit: src/sys/arch/amd64/conf
On Tue, 15 Aug 2017, Martin Husemann wrote: On Tue, Aug 15, 2017 at 04:33:19PM +0200, Maxime Villard wrote: So we agree? Each compat should be independent. Yes. Well, not totally independent! We have module dependencies to enable the use of common code. It seems to me that re-implementing (copy-paste) a few functions for linux is a step towards direction, isn't it? No, it isn't (but it MAY be ok for real trivial ones). Untangling the maze, renaming the common functions and fixing the modularization for them is the way to go, IMO. Definitely agree here, 110% BTW, the "new" module we're recommending might better be called compat_utils rather than compat_common. +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: CVS commit: src/sys/arch/amd64/conf
On Tue, 15 Aug 2017, Maxime Villard wrote: Le 15/08/2017 à 14:50, Martin Husemann a écrit : On Tue, Aug 15, 2017 at 02:48:39PM +0200, Maxime Villard wrote: Why is it a bad idea re-implement the few compat_xx functions used in compat_linux? This would eliminate the dependency, and a single modload would suffice. Move them into a common module required by all current consumers. This module already exists, and it's modules/compat. The problem, again, is that this module will register new syscalls, while we only want the functions to be available. And it's more than that: if dynamically loaded, this module may conflict with the kernel, since several COMPAT_xx options are enabled in GENERIC by default. So you get the same functions twice. Create a new module (perhaps compat_common) for these functions, and add the new module's name to the "required" list in both compat_linux and compat. If either module is built-in, the files.xxx dependencies will (should) include the compat_common code, including its module header, so dynamically loading other modules will not try to autoload the common code. +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: CVS commit: src/sys/arch/amd64/conf
Le 15/08/2017 à 16:38, Martin Husemann a écrit : On Tue, Aug 15, 2017 at 04:33:19PM +0200, Maxime Villard wrote: So we agree? Each compat should be independent. Yes. It seems to me that re-implementing (copy-paste) a few functions for linux is a step towards direction, isn't it? No, it isn't (but it MAY be ok for real trivial ones). Untangling the maze, renaming the common functions and fixing the modularization for them is the way to go, IMO. You can't rename them, since they are used by the real COMPAT_xx options; eg, compat_43_sys_lseek can't be renamed to compat_common_sys_lseek, since it is the COMPAT_43-specific version. This version *happens* to be compatible with that of linux, so it's borrowed from compat_linux, for no other reason than not duplicating code, and at the cost of an inextricable implementation. Also, after giving a closer look, it is not possible to ship the compat functions by default and have several modules that just register the syscalls, since within these functions, there are still many #ifdef COMPAT. And that's why I think that the compat_43_*/etc functions used in linux should be re-implemented... Maxime
Re: CVS commit: src/sys/arch/amd64/conf
On Tue, Aug 15, 2017 at 04:33:19PM +0200, Maxime Villard wrote: > So we agree? Each compat should be independent. Yes. > It seems to me that > re-implementing (copy-paste) a few functions for linux is a step towards > direction, isn't it? No, it isn't (but it MAY be ok for real trivial ones). Untangling the maze, renaming the common functions and fixing the modularization for them is the way to go, IMO. Martin
Re: CVS commit: src/sys/arch/amd64/conf
Le 15/08/2017 à 15:18, Martin Husemann a écrit : On Tue, Aug 15, 2017 at 03:05:31PM +0200, Maxime Villard wrote: This module already exists, and it's modules/compat. The problem, again, is that this module will register new syscalls, while we only want the functions to be available. And it's more than that: if dynamically loaded, this module may conflict with the kernel, since several COMPAT_xx options are enabled in GENERIC by default. So you get the same functions twice. As you say, a single "one compat fits all" module does not work, it needs to be multiple ones, maybe even single function modules. The (partial) options enabled in kernel would then make the relevant modules be build in, and the module loader will resolve them automatically. So we agree? Each compat should be independent. It seems to me that re-implementing (copy-paste) a few functions for linux is a step towards direction, isn't it? Maxime
Re: CVS commit: src/sys/arch/amd64/conf
On Tue, Aug 15, 2017 at 03:05:31PM +0200, Maxime Villard wrote: > This module already exists, and it's modules/compat. The problem, again, > is that this module will register new syscalls, while we only want the > functions to be available. And it's more than that: if dynamically loaded, > this module may conflict with the kernel, since several COMPAT_xx options > are enabled in GENERIC by default. So you get the same functions twice. As you say, a single "one compat fits all" module does not work, it needs to be multiple ones, maybe even single function modules. The (partial) options enabled in kernel would then make the relevant modules be build in, and the module loader will resolve them automatically. Martin
Re: CVS commit: src/sys/arch/amd64/conf
Le 15/08/2017 à 14:50, Martin Husemann a écrit : On Tue, Aug 15, 2017 at 02:48:39PM +0200, Maxime Villard wrote: Why is it a bad idea re-implement the few compat_xx functions used in compat_linux? This would eliminate the dependency, and a single modload would suffice. Move them into a common module required by all current consumers. This module already exists, and it's modules/compat. The problem, again, is that this module will register new syscalls, while we only want the functions to be available. And it's more than that: if dynamically loaded, this module may conflict with the kernel, since several COMPAT_xx options are enabled in GENERIC by default. So you get the same functions twice. Maxime
Re: CVS commit: src/sys/arch/amd64/conf
On Tue, Aug 15, 2017 at 02:48:39PM +0200, Maxime Villard wrote: > Why is it a bad idea re-implement the few compat_xx functions used in > compat_linux? This would eliminate the dependency, and a single modload > would suffice. Move them into a common module required by all current consumers. Martin
Re: CVS commit: src/sys/arch/amd64/conf
Le 04/08/2017 à 10:00, matthew green a écrit : the setup comes from before modules and it allows code sharing because the old 43 version matches other systems. so there's a single implementation of this code for a large number of consumers, and the name of it describes where it comes from. this is entirely as designed and desired. Thinking about this again; this may have been desired, but it's clearly a wrong design - and it also was with config(5), regardless of the modules. The user finds himself in a situation where if he wants to use a linux binary, he has to enable a whole bunch of unrelated compat options, just because our compat_linux borrows one function here, and another there, etc. While I agree that deduplicating code is a good thing in general, it certainly is not when the subsystems that share the code are this distant, and when these subsystems end up being less user-friendly. Why is it a bad idea re-implement the few compat_xx functions used in compat_linux? This would eliminate the dependency, and a single modload would suffice. Maxime
Re: CVS commit: src/sys/arch/amd64/conf
Le 04/08/2017 à 10:00, matthew green a écrit : Maxime Villard writes: Yes, I saw that too a few days later when moving the compat_freebsd files and trying to do a modload. I went "what the hell is this", but didn't do anything. What I could see, is that many of our compat options are at some point using at least one compat_43_* function, even if they have nothing to do with 4.3BSD. It appears that people just chose to use them, because they were convenient, instead of re-writing them on purpose. The assumption was that the compat_43 functions would always be there; that's obviously a wrong assumption. As a quick fix, I can revert my change. But that does not fix this mess; we would have to either rename compat_43_* to compat_common_* and compile them by default (ie, without depending on an #ifdef COMPAT_43), or we would have to implement the functions in all of the compat options with proper names (eg compat_43_sys_lseek -> freebsd_sys_lseek). please revert your change (for now?). thanks. Alright, I'll do that for now. Frankly, this is a huge mess. i don't agree. the setup comes from before modules and it allows code sharing because the old 43 version matches other systems. so there's a single implementation of this code for a large number of consumers, and the name of it describes where it comes from. Yes, but the fact that the availability of the compat_43_* functions depends on #ifdef COMPAT_43, while they are just common functions used in a lot of places, is wrong. And it has nothing to do with the modules, it was already wrong before they were introduced (even if it used to be harmless). As a third (and simpler) solution, we could make sure that these functions are compiled regardless of COMPAT_43, without renaming them. Maxime
re: CVS commit: src/sys/arch/amd64/conf
Maxime Villard writes: > Yes, I saw that too a few days later when moving the compat_freebsd files and > trying to do a modload. I went "what the hell is this", but didn't do > anything. > > What I could see, is that many of our compat options are at some point using > at least one compat_43_* function, even if they have nothing to do with > 4.3BSD. > > It appears that people just chose to use them, because they were convenient, > instead of re-writing them on purpose. The assumption was that the compat_43 > functions would always be there; that's obviously a wrong assumption. > > As a quick fix, I can revert my change. But that does not fix this mess; we > would have to either rename compat_43_* to compat_common_* and compile them by > default (ie, without depending on an #ifdef COMPAT_43), or we would have to > implement the functions in all of the compat options with proper names (eg > compat_43_sys_lseek -> freebsd_sys_lseek). please revert your change (for now?). thanks. > Frankly, this is a huge mess. i don't agree. the setup comes from before modules and it allows code sharing because the old 43 version matches other systems. so there's a single implementation of this code for a large number of consumers, and the name of it describes where it comes from. this is entirely as designed and desired. normal kernels handle this fine within the config(5) framework. that modules don't know how to do this properly yet is not the existing code's problem -- that's just other of the issues that modules have that are why they're not yet an acceptible way to replace functionality. .mrg.
Re: CVS commit: src/sys/arch/amd64/conf
Le 03/08/2017 à 23:32, co...@sdf.org a écrit : On Fri, Jul 28, 2017 at 04:10:29PM +, Maxime Villard wrote: Module Name:src Committed By: maxv Date: Fri Jul 28 16:10:29 UTC 2017 Modified Files: src/sys/arch/amd64/conf: GENERIC XEN3_DOM0 XEN3_DOMU Log Message: After a careful review, and all things considered, disable compat43 by default on amd64. The use case is limited, the potential for damage too high, and it is safer to run a BSD4.3 binary on i386 since the kernel does not have to go through netbsd32 - which may not correctly reproduce i386. To generate a diff of this commit: cvs rdiff -u -r1.461 -r1.462 src/sys/arch/amd64/conf/GENERIC cvs rdiff -u -r1.136 -r1.137 src/sys/arch/amd64/conf/XEN3_DOM0 cvs rdiff -u -r1.75 -r1.76 src/sys/arch/amd64/conf/XEN3_DOMU This breaks running compat_linux as a kernel module: Aug 4 00:19:19 loggy /netbsd: kobj_checksyms, 974: [compat_linux]: linker error: symbol `compat_43_sys_sethostname' not found Aug 4 00:19:19 loggy /netbsd: kobj_checksyms, 974: [compat_linux]: linker error: symbol `compat_43_sys_lseek' not found Aug 4 00:19:19 loggy /netbsd: WARNING: module error: unable to affix module `compat_linux', error 8 I believe paulg made PR kern/51597 for similar issues Yes, I saw that too a few days later when moving the compat_freebsd files and trying to do a modload. I went "what the hell is this", but didn't do anything. What I could see, is that many of our compat options are at some point using at least one compat_43_* function, even if they have nothing to do with 4.3BSD. It appears that people just chose to use them, because they were convenient, instead of re-writing them on purpose. The assumption was that the compat_43 functions would always be there; that's obviously a wrong assumption. As a quick fix, I can revert my change. But that does not fix this mess; we would have to either rename compat_43_* to compat_common_* and compile them by default (ie, without depending on an #ifdef COMPAT_43), or we would have to implement the functions in all of the compat options with proper names (eg compat_43_sys_lseek -> freebsd_sys_lseek). Frankly, this is a huge mess. Maxime
Re: CVS commit: src/sys/arch/amd64/conf
paulg adds: This is not making GENERIC fail because COMPAT_43 is not really removed on it. $ nm /home/fly/amd/sys/arch/amd64/compile/GENERIC/netbsd |grep compat_43 80403485 T compat_43_netbsd32_fstat43 8040371a T compat_43_netbsd32_killpg 80403431 T compat_43_netbsd32_lstat43 804037b5 T compat_43_netbsd32_oaccept ... This is from: sys/compat/netbsd32/files.netbsd32: filecompat/netbsd32/netbsd32_compat_43.ccompat_netbsd32 & (compat_43 | compat_sunos | compat_linux32) So with COMPAT_LINUX32, it still builds the COMPAT_43 code.
Re: CVS commit: src/sys/arch/amd64/conf
On Fri, Jul 28, 2017 at 04:10:29PM +, Maxime Villard wrote: > Module Name: src > Committed By: maxv > Date: Fri Jul 28 16:10:29 UTC 2017 > > Modified Files: > src/sys/arch/amd64/conf: GENERIC XEN3_DOM0 XEN3_DOMU > > Log Message: > After a careful review, and all things considered, disable compat43 by > default on amd64. The use case is limited, the potential for damage too > high, and it is safer to run a BSD4.3 binary on i386 since the kernel does > not have to go through netbsd32 - which may not correctly reproduce i386. > > > To generate a diff of this commit: > cvs rdiff -u -r1.461 -r1.462 src/sys/arch/amd64/conf/GENERIC > cvs rdiff -u -r1.136 -r1.137 src/sys/arch/amd64/conf/XEN3_DOM0 > cvs rdiff -u -r1.75 -r1.76 src/sys/arch/amd64/conf/XEN3_DOMU This breaks running compat_linux as a kernel module: Aug 4 00:19:19 loggy /netbsd: kobj_checksyms, 974: [compat_linux]: linker error: symbol `compat_43_sys_sethostname' not found Aug 4 00:19:19 loggy /netbsd: kobj_checksyms, 974: [compat_linux]: linker error: symbol `compat_43_sys_lseek' not found Aug 4 00:19:19 loggy /netbsd: WARNING: module error: unable to affix module `compat_linux', error 8 I believe paulg made PR kern/51597 for similar issues
Re: CVS commit: src/sys/arch/amd64/conf
On Sat, 29 Jul 2017, Paul Goyette wrote: On Fri, 28 Jul 2017, Maxime Villard wrote: Module Name:src Committed By: maxv Date: Fri Jul 28 16:10:29 UTC 2017 Modified Files: src/sys/arch/amd64/conf: GENERIC XEN3_DOM0 XEN3_DOMU Log Message: After a careful review, and all things considered, disable compat43 by default on amd64. The use case is limited, the potential for damage too high, and it is safer to run a BSD4.3 binary on i386 since the kernel does not have to go through netbsd32 - which may not correctly reproduce i386. Should COMPAT43 also be removed from the default build of compat module? See line #26 in src/sys/modules/netbsd/Makefile Thanks to maxv@ for pointing out the error in the path above. Please s;/netbsd;/compat; +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: CVS commit: src/sys/arch/amd64/conf
On Fri, 28 Jul 2017, Maxime Villard wrote: Module Name:src Committed By: maxv Date: Fri Jul 28 16:10:29 UTC 2017 Modified Files: src/sys/arch/amd64/conf: GENERIC XEN3_DOM0 XEN3_DOMU Log Message: After a careful review, and all things considered, disable compat43 by default on amd64. The use case is limited, the potential for damage too high, and it is safer to run a BSD4.3 binary on i386 since the kernel does not have to go through netbsd32 - which may not correctly reproduce i386. Should COMPAT43 also be removed from the default build of compat module? See line #26 in src/sys/modules/netbsd/Makefile +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: CVS commit: src/sys/arch/amd64/conf
On Sat, Nov 26, 2016 at 09:21:17PM +1100, matthew green wrote: > > Modified Files: > >src/sys/arch/amd64/conf: GENERIC > > > > Log Message: > > 1.6 was the first amd64 release. (although it didn't really work too well > > before -5) > > dunno what you're talking about. i ran it for many years before -5. If you like :-) I'm just going by what I saw in gnats at the time. -- David A. Holland dholl...@netbsd.org
re: CVS commit: src/sys/arch/amd64/conf
"David A. Holland" writes: > Module Name: src > Committed By: dholland > Date: Sat Nov 26 01:09:33 UTC 2016 > > Modified Files: > src/sys/arch/amd64/conf: GENERIC > > Log Message: > 1.6 was the first amd64 release. (although it didn't really work too well > before -5) dunno what you're talking about. i ran it for many years before -5. .mrg.
Re: CVS commit: src/sys/arch/amd64/conf
will do. christos
re: CVS commit: src/sys/arch/amd64/conf
"Christos Zoulas" writes: > Module Name: src > Committed By: christos > Date: Sun Aug 7 10:39:59 UTC 2016 > > Modified Files: > src/sys/arch/amd64/conf: MODULAR > > Log Message: > Use "-no" and add more cloners. please bump the config version and the minimum required config version. thanks. .mrg. ps: since we stopped failing on "no options" that don't exist, i'd actually be more inclined to simply make "no device " work as the same by default than add this (either way, the version matters.)
Re: CVS commit: src/sys/arch/amd64/conf
On Jan 10, 2:29pm, ryo...@yk.rim.or.jp (Ryo ONODERA) wrote: -- Subject: Re: CVS commit: src/sys/arch/amd64/conf | It is not needed. I've removed it already! christos
Re: CVS commit: src/sys/arch/amd64/conf
From: Ryo ONODERA , Date: Sun, 10 Jan 2016 13:04:07 +0900 (JST) > Hi, > > From: chris...@zoulas.com (Christos Zoulas), Date: Sat, 9 Jan 2016 23:01:25 > -0500 > >> On Jan 10, 12:57pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: >> -- Subject: Re: CVS commit: src/sys/arch/amd64/conf >> >> | christos@ wrote: >> | >> | > Modified Files: >> | > src/sys/arch/amd64/conf: GENERIC >> | > >> | > Log Message: >> | > PR/50636: Ryo ONODERA: Add scsibus to vioscsi >> | >> | >> +#mos* at uhub? port ? # Moschip MCS7730/MCS7830/MCS7832 based >> adapters >> | >> | What's this one? >> | >> | >> +scsibus* at vioscsi? >> | >> | Why the existing common "scsibus* at scsi" doesn't work for vioscsi? >> >> I don't know; that's what he reported. I did not need it. > > I will check again whether it is really needed or not. It is not needed. Sorry. -- Ryo ONODERA // ryo...@yk.rim.or.jp PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
Re: CVS commit: src/sys/arch/amd64/conf
Hi, From: chris...@zoulas.com (Christos Zoulas), Date: Sat, 9 Jan 2016 23:01:25 -0500 > On Jan 10, 12:57pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: > -- Subject: Re: CVS commit: src/sys/arch/amd64/conf > > | christos@ wrote: > | > | > Modified Files: > | > src/sys/arch/amd64/conf: GENERIC > | > > | > Log Message: > | > PR/50636: Ryo ONODERA: Add scsibus to vioscsi > | > | >> +#mos* at uhub? port ? # Moschip MCS7730/MCS7830/MCS7832 based > adapters > | > | What's this one? > | > | >> +scsibus* at vioscsi? > | > | Why the existing common "scsibus* at scsi" doesn't work for vioscsi? > > I don't know; that's what he reported. I did not need it. I will check again whether it is really needed or not. -- Ryo ONODERA // ryo...@yk.rim.or.jp PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
Re: CVS commit: src/sys/arch/amd64/conf
On Jan 10, 12:57pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: CVS commit: src/sys/arch/amd64/conf | christos@ wrote: | | > Modified Files: | > src/sys/arch/amd64/conf: GENERIC | > | > Log Message: | > PR/50636: Ryo ONODERA: Add scsibus to vioscsi | | >> +#mos* at uhub? port ? # Moschip MCS7730/MCS7830/MCS7832 based adapters | | What's this one? | | >> +scsibus* at vioscsi? | | Why the existing common "scsibus* at scsi" doesn't work for vioscsi? I don't know; that's what he reported. I did not need it. christos
Re: CVS commit: src/sys/arch/amd64/conf
christos@ wrote: > Modified Files: > src/sys/arch/amd64/conf: GENERIC > > Log Message: > PR/50636: Ryo ONODERA: Add scsibus to vioscsi >> +#mos* at uhub? port ? # Moschip MCS7730/MCS7830/MCS7832 based >> adapters What's this one? >> +scsibus* at vioscsi? Why the existing common "scsibus* at scsi" doesn't work for vioscsi? --- Izumi Tsutsui
Re: CVS commit: src/sys/arch/amd64/conf
On Sun, Sep 6, 2015 at 4:17 PM, Masao Uebayashi wrote:
> Module Name:src
> Committed By: uebayasi
> Date: Sun Sep 6 07:17:14 UTC 2015
>
> Modified Files:
> src/sys/arch/amd64/conf: Makefile.amd64 files.amd64
>
> Log Message:
> Define MD start code at the top of files.${MACHINE} relying on config(1)'s
> deterministic file output order. No need to define ${MD_OBJS} and its
> useless,
> explicit compile rules.
Although it was true that config(1) preserves file order, I have
mistakenly reordered files in ${OBJS}, that is passed to ${LD}, and
the first file (locore.o) has been mistakenly linked after all *.o
files derived from *.c. Just fixed now in sys/conf/Makefile.kern.inc
Rev. 1.244.
(Kernel booted because boot loader honored ELF entry address.)
Re: CVS commit: src/sys/arch/amd64/conf
On Wed, Oct 15, 2014 at 08:28:31PM +0700, Robert Elz wrote: > [...] > | Including "std.ath_hal" means that you pull in ath device code in your > | kernel. > > No it doesn't. All it is is a bunch of option definitions, by themselves, > those do (or should do) nothing. What's more, I verified that my DomU > kernels from before this change had no ath related code in them at all (I'm > not interested in the possibility of pci passthrough, or at least, not > right now) and my Dom0 kernel did (as it was intended to). OK, I didn't really check this, but it removing ath from the kernel config file really cause all ath-related files to be ommitted, then there's no reason to not have std.ath_hal inclued by default. One can still use "no options ..." if he really wants to strip down the kernel with only the required ath bits. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/sys/arch/amd64/conf
Date:Sun, 12 Oct 2014 00:17:22 +0900 From:Masao Uebayashi Message-ID: For what it is worth, this change (below) just "bit" me - I did my first new builds for a couple of weeks, and my own Dom0 config failed to build (because even though the standard XEN3_DOM0 got the include ... added to it, my private config file, that is tailored to my sustem (which does have atheros wireless) did not have that, just the "ath* at ..." stuff. The link failed in a way that was (to me) bizarre... | On Sun, Oct 12, 2014 at 12:05 AM, Manuel Bouyer wrote: | > On Sat, Oct 11, 2014 at 09:50:03AM +, Masao Uebayashi wrote: | >> Don't include std.ath_hal for XEN3_DOMU. | > | > Why ? | Including "std.ath_hal" means that you pull in ath device code in your | kernel. No it doesn't. All it is is a bunch of option definitions, by themselves, those do (or should do) nothing. What's more, I verified that my DomU kernels from before this change had no ath related code in them at all (I'm not interested in the possibility of pci passthrough, or at least, not right now) and my Dom0 kernel did (as it was intended to). As I see it, all the ath code is conditioned by at least requiring "ath" which is obtained by having "ath* at" in the config file somewhjere (which normally DOM0 does, and DOMU does not). That includes ath code in DOM0 and excludes it from DOMU, and all this has seemed to work essentially forever. What has changed, or is changing that makes specifying a useless option do anything different? The options to include the various different ath drivers - or whatever they do - might truly be better explicitly listed in the config files, so only the appropriate ones will be included, but just including all or nothing via std.ath_hal being there or not doesn't seem like it is the correct level of granualarity. That is, if the way the drivers are written (currently) even allows selecting one, or two, but not all (no idea, I have never tried.) Now, clearly fixing this for my kernel config just meant adding the include line (once I found this particular change) - but I don't really think that's the way kernel config files should be written. kre
Re: CVS commit: src/sys/arch/amd64/conf
I think this can be fixed by providing new selection statements, "flags" and/or "params", which are meant to enable flags/params, not options/attributes. For ath's case, "options ATHHAL_AR5210" means that you want to include more *.c's for that option. "params ATHHAL_DEBUG" means that you want to change *.o with that flags/params set. In other words, "flags ..." or "params ..." never add *.c and dependencies in your kernel.
Re: CVS commit: src/sys/arch/amd64/conf
On Sun, Oct 12, 2014 at 4:35 AM, Manuel Bouyer wrote:
> On Sun, Oct 12, 2014 at 04:23:17AM +0900, Masao Uebayashi wrote:
>> On Sun, Oct 12, 2014 at 3:48 AM, Manuel Bouyer
>> wrote:
>> > On Sun, Oct 12, 2014 at 03:35:48AM +0900, Masao Uebayashi wrote:
>> >> On Sun, Oct 12, 2014 at 3:06 AM, Manuel Bouyer
>> >> wrote:
>> >> > On Sun, Oct 12, 2014 at 12:17:22AM +0900, Masao Uebayashi wrote:
>> >> >> On Sun, Oct 12, 2014 at 12:05 AM, Manuel Bouyer
>> >> >> wrote:
>> >> >> > On Sat, Oct 11, 2014 at 09:50:03AM +, Masao Uebayashi wrote:
>> >> >> >> Module Name: src
>> >> >> >> Committed By: uebayasi
>> >> >> >> Date: Sat Oct 11 09:50:03 UTC 2014
>> >> >> >>
>> >> >> >> Modified Files:
>> >> >> >> src/sys/arch/amd64/conf: XEN3_DOM0 std.xen
>> >> >> >>
>> >> >> >> Log Message:
>> >> >> >> Don't include std.ath_hal for XEN3_DOMU.
>> >> >> >
>> >> >> > Why ?
>> >> >> > We still support PCI pass-through, so we could have a ath in a domU
>> >> >>
>> >> >> In that case you have to enable xpci/pci at first.
>> >> >>
>> >> >> Including "std.ath_hal" means that you pull in ath device code in your
>> >> >> kernel. But you don't have no parent buses. This might be OK for
>> >> >> ath(4), but in general, it means that config(1) doesn't resolve
>> >> >> dependency, and your kernel may be bloated by unnecessary code.
>> >> >
>> >> > why isn't this compiled in only when ath(4) is inclued in config file ?
>> >> > isn't that what attributes are for ?
>> >>
>> >> I don't understand. If you say "config file", is it files.*
>> >> (definition) or std.* (selection)?
>> >
>> > OK, I see. But I still think config should be able to include theses
>> > only if ath or athn is there; wouldn't adding " & ath" at appropriate
>> > places
>> > in files.ath_hal be enough for this to happen ?
>>
>> Instead of:
>>
>> ath_common_files.c ath & athn
>>
>> You can do:
>>
>> define ath: ath_common
>> define athn: ath_common
>> define ath_common
>> ath_common_files.c ath_common
>>
>> I don't understand why you need & or | or those expressions. I think
>> >99% are file with dependency. Or do you want more complex world like
>> this?
>>
>> http://nxr.netbsd.org/source/xref/src-freebsd/sys/conf/files
>
> No, I just want e.g. "options ATHHAL_AR5210" to be a noop if
> ath(4) is not inclued in the kernel config file.
> This way you don't need to mess with these options at all, unless
> you really want a stripped-down kernel.
Understood.
The problem is, there are options that select something, and those
that define flags/params. Attributes (modules) that are neighter
(pseudo) devices or filesystems are selected only by options.
De-selection ("no ...") has the same problem I'll consider this.
Re: CVS commit: src/sys/arch/amd64/conf
On Sun, Oct 12, 2014 at 04:23:17AM +0900, Masao Uebayashi wrote: > On Sun, Oct 12, 2014 at 3:48 AM, Manuel Bouyer wrote: > > On Sun, Oct 12, 2014 at 03:35:48AM +0900, Masao Uebayashi wrote: > >> On Sun, Oct 12, 2014 at 3:06 AM, Manuel Bouyer > >> wrote: > >> > On Sun, Oct 12, 2014 at 12:17:22AM +0900, Masao Uebayashi wrote: > >> >> On Sun, Oct 12, 2014 at 12:05 AM, Manuel Bouyer > >> >> wrote: > >> >> > On Sat, Oct 11, 2014 at 09:50:03AM +, Masao Uebayashi wrote: > >> >> >> Module Name: src > >> >> >> Committed By: uebayasi > >> >> >> Date: Sat Oct 11 09:50:03 UTC 2014 > >> >> >> > >> >> >> Modified Files: > >> >> >> src/sys/arch/amd64/conf: XEN3_DOM0 std.xen > >> >> >> > >> >> >> Log Message: > >> >> >> Don't include std.ath_hal for XEN3_DOMU. > >> >> > > >> >> > Why ? > >> >> > We still support PCI pass-through, so we could have a ath in a domU > >> >> > >> >> In that case you have to enable xpci/pci at first. > >> >> > >> >> Including "std.ath_hal" means that you pull in ath device code in your > >> >> kernel. But you don't have no parent buses. This might be OK for > >> >> ath(4), but in general, it means that config(1) doesn't resolve > >> >> dependency, and your kernel may be bloated by unnecessary code. > >> > > >> > why isn't this compiled in only when ath(4) is inclued in config file ? > >> > isn't that what attributes are for ? > >> > >> I don't understand. If you say "config file", is it files.* > >> (definition) or std.* (selection)? > > > > OK, I see. But I still think config should be able to include theses > > only if ath or athn is there; wouldn't adding " & ath" at appropriate places > > in files.ath_hal be enough for this to happen ? > > Instead of: > > ath_common_files.c ath & athn > > You can do: > > define ath: ath_common > define athn: ath_common > define ath_common > ath_common_files.c ath_common > > I don't understand why you need & or | or those expressions. I think > >99% are file with dependency. Or do you want more complex world like > this? > > http://nxr.netbsd.org/source/xref/src-freebsd/sys/conf/files No, I just want e.g. "options ATHHAL_AR5210" to be a noop if ath(4) is not inclued in the kernel config file. This way you don't need to mess with these options at all, unless you really want a stripped-down kernel. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/sys/arch/amd64/conf
On Sun, Oct 12, 2014 at 3:48 AM, Manuel Bouyer wrote: > On Sun, Oct 12, 2014 at 03:35:48AM +0900, Masao Uebayashi wrote: >> On Sun, Oct 12, 2014 at 3:06 AM, Manuel Bouyer >> wrote: >> > On Sun, Oct 12, 2014 at 12:17:22AM +0900, Masao Uebayashi wrote: >> >> On Sun, Oct 12, 2014 at 12:05 AM, Manuel Bouyer >> >> wrote: >> >> > On Sat, Oct 11, 2014 at 09:50:03AM +, Masao Uebayashi wrote: >> >> >> Module Name: src >> >> >> Committed By: uebayasi >> >> >> Date: Sat Oct 11 09:50:03 UTC 2014 >> >> >> >> >> >> Modified Files: >> >> >> src/sys/arch/amd64/conf: XEN3_DOM0 std.xen >> >> >> >> >> >> Log Message: >> >> >> Don't include std.ath_hal for XEN3_DOMU. >> >> > >> >> > Why ? >> >> > We still support PCI pass-through, so we could have a ath in a domU >> >> >> >> In that case you have to enable xpci/pci at first. >> >> >> >> Including "std.ath_hal" means that you pull in ath device code in your >> >> kernel. But you don't have no parent buses. This might be OK for >> >> ath(4), but in general, it means that config(1) doesn't resolve >> >> dependency, and your kernel may be bloated by unnecessary code. >> > >> > why isn't this compiled in only when ath(4) is inclued in config file ? >> > isn't that what attributes are for ? >> >> I don't understand. If you say "config file", is it files.* >> (definition) or std.* (selection)? > > OK, I see. But I still think config should be able to include theses > only if ath or athn is there; wouldn't adding " & ath" at appropriate places > in files.ath_hal be enough for this to happen ? Instead of: ath_common_files.c ath & athn You can do: define ath: ath_common define athn: ath_common define ath_common ath_common_files.c ath_common I don't understand why you need & or | or those expressions. I think >99% are file with dependency. Or do you want more complex world like this? http://nxr.netbsd.org/source/xref/src-freebsd/sys/conf/files
Re: CVS commit: src/sys/arch/amd64/conf
On Sun, Oct 12, 2014 at 03:35:48AM +0900, Masao Uebayashi wrote: > On Sun, Oct 12, 2014 at 3:06 AM, Manuel Bouyer wrote: > > On Sun, Oct 12, 2014 at 12:17:22AM +0900, Masao Uebayashi wrote: > >> On Sun, Oct 12, 2014 at 12:05 AM, Manuel Bouyer > >> wrote: > >> > On Sat, Oct 11, 2014 at 09:50:03AM +, Masao Uebayashi wrote: > >> >> Module Name: src > >> >> Committed By: uebayasi > >> >> Date: Sat Oct 11 09:50:03 UTC 2014 > >> >> > >> >> Modified Files: > >> >> src/sys/arch/amd64/conf: XEN3_DOM0 std.xen > >> >> > >> >> Log Message: > >> >> Don't include std.ath_hal for XEN3_DOMU. > >> > > >> > Why ? > >> > We still support PCI pass-through, so we could have a ath in a domU > >> > >> In that case you have to enable xpci/pci at first. > >> > >> Including "std.ath_hal" means that you pull in ath device code in your > >> kernel. But you don't have no parent buses. This might be OK for > >> ath(4), but in general, it means that config(1) doesn't resolve > >> dependency, and your kernel may be bloated by unnecessary code. > > > > why isn't this compiled in only when ath(4) is inclued in config file ? > > isn't that what attributes are for ? > > I don't understand. If you say "config file", is it files.* > (definition) or std.* (selection)? OK, I see. But I still think config should be able to include theses only if ath or athn is there; wouldn't adding " & ath" at appropriate places in files.ath_hal be enough for this to happen ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/sys/arch/amd64/conf
On Sun, Oct 12, 2014 at 3:06 AM, Manuel Bouyer wrote: > On Sun, Oct 12, 2014 at 12:17:22AM +0900, Masao Uebayashi wrote: >> On Sun, Oct 12, 2014 at 12:05 AM, Manuel Bouyer >> wrote: >> > On Sat, Oct 11, 2014 at 09:50:03AM +, Masao Uebayashi wrote: >> >> Module Name: src >> >> Committed By: uebayasi >> >> Date: Sat Oct 11 09:50:03 UTC 2014 >> >> >> >> Modified Files: >> >> src/sys/arch/amd64/conf: XEN3_DOM0 std.xen >> >> >> >> Log Message: >> >> Don't include std.ath_hal for XEN3_DOMU. >> > >> > Why ? >> > We still support PCI pass-through, so we could have a ath in a domU >> >> In that case you have to enable xpci/pci at first. >> >> Including "std.ath_hal" means that you pull in ath device code in your >> kernel. But you don't have no parent buses. This might be OK for >> ath(4), but in general, it means that config(1) doesn't resolve >> dependency, and your kernel may be bloated by unnecessary code. > > why isn't this compiled in only when ath(4) is inclued in config file ? > isn't that what attributes are for ? I don't understand. If you say "config file", is it files.* (definition) or std.* (selection)?
Re: CVS commit: src/sys/arch/amd64/conf
On Sun, Oct 12, 2014 at 12:17:22AM +0900, Masao Uebayashi wrote: > On Sun, Oct 12, 2014 at 12:05 AM, Manuel Bouyer > wrote: > > On Sat, Oct 11, 2014 at 09:50:03AM +, Masao Uebayashi wrote: > >> Module Name: src > >> Committed By: uebayasi > >> Date: Sat Oct 11 09:50:03 UTC 2014 > >> > >> Modified Files: > >> src/sys/arch/amd64/conf: XEN3_DOM0 std.xen > >> > >> Log Message: > >> Don't include std.ath_hal for XEN3_DOMU. > > > > Why ? > > We still support PCI pass-through, so we could have a ath in a domU > > In that case you have to enable xpci/pci at first. > > Including "std.ath_hal" means that you pull in ath device code in your > kernel. But you don't have no parent buses. This might be OK for > ath(4), but in general, it means that config(1) doesn't resolve > dependency, and your kernel may be bloated by unnecessary code. why isn't this compiled in only when ath(4) is inclued in config file ? isn't that what attributes are for ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/sys/arch/amd64/conf
On Sun, Oct 12, 2014 at 12:05 AM, Manuel Bouyer wrote: > On Sat, Oct 11, 2014 at 09:50:03AM +, Masao Uebayashi wrote: >> Module Name: src >> Committed By: uebayasi >> Date: Sat Oct 11 09:50:03 UTC 2014 >> >> Modified Files: >> src/sys/arch/amd64/conf: XEN3_DOM0 std.xen >> >> Log Message: >> Don't include std.ath_hal for XEN3_DOMU. > > Why ? > We still support PCI pass-through, so we could have a ath in a domU In that case you have to enable xpci/pci at first. Including "std.ath_hal" means that you pull in ath device code in your kernel. But you don't have no parent buses. This might be OK for ath(4), but in general, it means that config(1) doesn't resolve dependency, and your kernel may be bloated by unnecessary code. (config(1) is not great in reporting dependency errors yet.)
Re: CVS commit: src/sys/arch/amd64/conf
On Sat, Oct 11, 2014 at 09:50:03AM +, Masao Uebayashi wrote: > Module Name: src > Committed By: uebayasi > Date: Sat Oct 11 09:50:03 UTC 2014 > > Modified Files: > src/sys/arch/amd64/conf: XEN3_DOM0 std.xen > > Log Message: > Don't include std.ath_hal for XEN3_DOMU. Why ? We still support PCI pass-through, so we could have a ath in a domU -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/sys/arch/amd64/conf
In article <20140612192538.GA2882@neva>, Alexander Nasonov wrote: >matthew green wrote: >> this comment probably would be nice if it was with all instances >> of INET6, not just amd64 GENERIC. it certainly will help me a >> couple of times a year when i end up forgetting... > >I looked at this. There are 138 files in conf directories with both >INET6 and stf in them. It's easier to revert my comment now after >Christos changed the code to print #error. Just revert it, it should be done differently. christos
Re: CVS commit: src/sys/arch/amd64/conf
matthew green wrote: > this comment probably would be nice if it was with all instances > of INET6, not just amd64 GENERIC. it certainly will help me a > couple of times a year when i end up forgetting... I looked at this. There are 138 files in conf directories with both INET6 and stf in them. It's easier to revert my comment now after Christos changed the code to print #error. Alex
re: CVS commit: src/sys/arch/amd64/conf
"Alexander Nasonov" writes: > Module Name: src > Committed By: alnsn > Date: Thu Jun 12 12:13:36 UTC 2014 > > Modified Files: > src/sys/arch/amd64/conf: GENERIC > > Log Message: > Add a comment about disabling INET6. Should fix kern/48901. this comment probably would be nice if it was with all instances of INET6, not just amd64 GENERIC. it certainly will help me a couple of times a year when i end up forgetting... could you look at this? thanks. .mrg.
Re: CVS commit: src/sys/arch/amd64/conf
Am 15.03.14 20:18, schrieb John Nemeth: > On Mar 15, 1:50pm, "Jonathan A. Kollasch" wrote: > } > } Module Name:src > } Committed By: jakllsch > } Date: Sat Mar 15 13:50:01 UTC 2014 > } > } Modified Files: > } src/sys/arch/amd64/conf: XEN3_DOMU > } > } Log Message: > } Enable PCI support in amd64 XEN3_DOMU config to match i386 XEN3_DOMU config. > > PCI support in a DOMU kernel would only be useful when the > DOM0 is setup with pci passthrough for some device, which isn't > the norm. My answer would be to go the opposite way and disable > PCI support in both kernels. Also, simply enabling PCI support > without adding a whole schwak of PCI devices isn't very useful. > As well, I don't think PCI passthrough is working with modern > versions of Xen. PCI passthrough does work as upstream QEMU got the patches now. The actual missing part is the NetBSD adaption of the PCI access code in QEMU and in libxl. Christoph
Re: CVS commit: src/sys/arch/amd64/conf
John Nemeth writes: > On Mar 15, 1:50pm, "Jonathan A. Kollasch" wrote: > } > } Module Name:src > } Committed By: jakllsch > } Date: Sat Mar 15 13:50:01 UTC 2014 > } > } Modified Files: > } src/sys/arch/amd64/conf: XEN3_DOMU > } > } Log Message: > } Enable PCI support in amd64 XEN3_DOMU config to match i386 XEN3_DOMU config. > > PCI support in a DOMU kernel would only be useful when the > DOM0 is setup with pci passthrough for some device, which isn't > the norm. My answer would be to go the opposite way and disable > PCI support in both kernels. Also, simply enabling PCI support > without adding a whole schwak of PCI devices isn't very useful. > As well, I don't think PCI passthrough is working with modern > versions of Xen. John's comments seem sensible to me. Also, I find using PCI passthrough to be very unusual. pgp8mWlUycFXS.pgp Description: PGP signature
Re: CVS commit: src/sys/arch/amd64/conf
John Nemeth writes: > On Mar 15, 1:50pm, "Jonathan A. Kollasch" wrote: > } > } Module Name:src > } Committed By: jakllsch > } Date: Sat Mar 15 13:50:01 UTC 2014 > } > } Modified Files: > } src/sys/arch/amd64/conf: XEN3_DOMU > } > } Log Message: > } Enable PCI support in amd64 XEN3_DOMU config to match i386 XEN3_DOMU config. > > PCI support in a DOMU kernel would only be useful when the > DOM0 is setup with pci passthrough for some device, which isn't > the norm. My answer would be to go the opposite way and disable > PCI support in both kernels. Also, simply enabling PCI support > without adding a whole schwak of PCI devices isn't very useful. > As well, I don't think PCI passthrough is working with modern > versions of Xen. John's comments seem sensible to me. Also, I find using PCI passthrough to be very unusual. pgpt4NlQQp6MV.pgp Description: PGP signature
Re: CVS commit: src/sys/arch/amd64/conf
On Mar 15, 1:50pm, "Jonathan A. Kollasch" wrote: } } Module Name: src } Committed By: jakllsch } Date: Sat Mar 15 13:50:01 UTC 2014 } } Modified Files: } src/sys/arch/amd64/conf: XEN3_DOMU } } Log Message: } Enable PCI support in amd64 XEN3_DOMU config to match i386 XEN3_DOMU config. PCI support in a DOMU kernel would only be useful when the DOM0 is setup with pci passthrough for some device, which isn't the norm. My answer would be to go the opposite way and disable PCI support in both kernels. Also, simply enabling PCI support without adding a whole schwak of PCI devices isn't very useful. As well, I don't think PCI passthrough is working with modern versions of Xen. }-- End of excerpt from "Jonathan A. Kollasch"
Re: CVS commit: src/sys/arch/amd64/conf
On Wed, Oct 23, 2013 at 05:22:49PM +, Matt Thomas wrote: > Module Name: src > Committed By: matt > Date: Wed Oct 23 17:22:49 UTC 2013 > > Modified Files: > src/sys/arch/amd64/conf: GENERIC XEN3_DOM0 > > Log Message: > Add xhci device I would like to state at this time that I am not directly responsible for any unexpected whatevers due to this change.
Re: CVS commit: src/sys/arch/amd64/conf
The problem is that i2c.c can be built either because some other driver needs "i2cbus" or because an instance of the "iic" driver is requested. Only in the latter case does CFDRIVER_DECL get added to ioconf.c. I think I'll have to split out the driver specific stuff into a separate file to fix this properly. -Original Message- From: Marc Balmer Sent: Monday, October 03, 2011 3:28 AM Newsgroups: gmane.os.netbsd.devel.cvs.full To: source-changes-full-qavaossjccednm+yrof...@public.gmane.org Subject: CVS commit: src/sys/arch/amd64/conf Module Name: src Committed By: mbalmer Date: Mon Oct 3 07:28:14 UTC 2011 Modified Files: src/sys/arch/amd64/conf: XEN3_DOM0 Log Message: Enable an iic(4) device to prevent a linker warning. To generate a diff of this commit: cvs rdiff -u -r1.71 -r1.72 src/sys/arch/amd64/conf/XEN3_DOM0 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Modified files: Index: src/sys/arch/amd64/conf/XEN3_DOM0 diff -u src/sys/arch/amd64/conf/XEN3_DOM0:1.71 src/sys/arch/amd64/conf/XEN3_DOM0:1.72 --- src/sys/arch/amd64/conf/XEN3_DOM0:1.71 Thu Aug 18 20:55:21 2011 +++ src/sys/arch/amd64/conf/XEN3_DOM0 Mon Oct 3 07:28:14 2011 @@ -1,4 +1,4 @@ -# $NetBSD: XEN3_DOM0,v 1.71 2011/08/18 20:55:21 jakllsch Exp $ +# $NetBSD: XEN3_DOM0,v 1.72 2011/10/03 07:28:14 mbalmer Exp $ include "arch/amd64/conf/std.xen" @@ -297,7 +297,7 @@ amdtemp* at pchb? # AMD CPU Temperatur # AMD 768 and 8111 power/ACPI controllers amdpm* at pci? dev ? function ? # RNG and SMBus 1.0 interface -#iic* at amdpm? # sensors below are on this bus +iic* at amdpm? # sensors below are on this bus # Thermal monitor and fan controller #dbcool* at iic? addr 0x2C # Unknown other motherboard(s)
Re: CVS commit: src/sys/arch/amd64/conf
On Aug,Monday 8 2011, at 6:13 PM, Jonathan A. Kollasch wrote: > Module Name: src > Committed By: jakllsch > Date: Mon Aug 8 16:13:42 UTC 2011 > > Modified Files: > src/sys/arch/amd64/conf: GENERIC INSTALL > > Log Message: > Finish reverting premature modularization of amd64 kernels. I object against this change please revert it. > > > To generate a diff of this commit: > cvs rdiff -u -r1.328 -r1.329 src/sys/arch/amd64/conf/GENERIC > cvs rdiff -u -r1.86 -r1.87 src/sys/arch/amd64/conf/INSTALL > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > > Modified files: > > Index: src/sys/arch/amd64/conf/GENERIC > diff -u src/sys/arch/amd64/conf/GENERIC:1.328 > src/sys/arch/amd64/conf/GENERIC:1.329 > --- src/sys/arch/amd64/conf/GENERIC:1.328 Sat Jul 30 18:41:34 2011 > +++ src/sys/arch/amd64/conf/GENERIC Mon Aug 8 16:13:42 2011 > @@ -1,4 +1,4 @@ > -# $NetBSD: GENERIC,v 1.328 2011/07/30 18:41:34 jmcneill Exp $ > +# $NetBSD: GENERIC,v 1.329 2011/08/08 16:13:42 jakllsch Exp $ > # > # GENERIC machine description file > # > @@ -22,15 +22,10 @@ > > options INCLUDE_CONFIG_FILE # embed config file in kernel binary > > -#ident "GENERIC-$Revision: 1.328 $" > +#ident "GENERIC-$Revision: 1.329 $" > > maxusers 64 # estimated number of users > > -# Common binary formats are statically compiled in by default. > -options EXEC_ELF32 # exec ELF 32-bits binaries > -#no options EXEC_ELF64 # exec ELF 64-bits binaries > -#no options EXEC_SCRIPT # exec #! scripts > - > # delay between "rebooting ..." message and hardware reset, in milliseconds > #options CPURESET_DELAY=2000 > > @@ -70,8 +65,6 @@ > options SYSVSEM # System V-like semaphores > options SYSVSHM # System V-like memory sharing > #options P1003_1B_SEMAPHORE # p1003.1b semaphore support > -no options AIO # POSIX asynchronous I/O, built as a module(7) > -no options MQUEUE # POSIX messsage queues, built as a module(7) > > options MODULAR # new style module(7) framework > options USERCONF# userconf(4) support > @@ -124,8 +117,9 @@ > > options COMPAT_OSSAUDIO > options COMPAT_NETBSD32 > -#options COMPAT_LINUX > -#options COMPAT_LINUX32 # req. COMPAT_LINUX and COMPAT_NETBSD32 > +options COMPAT_LINUX > +options COMPAT_LINUX32 # req. COMPAT_LINUX and COMPAT_NETBSD32 > +options EXEC_ELF32 > options COMPAT_BSDPTY # /dev/[pt]ty?? ptys. > > # Wedge support > @@ -139,23 +133,22 @@ > file-system MFS # memory file system > file-system NFS # Network File System client > file-system TMPFS # Efficient memory file-system > -# File systems, built as module(7)s by default > -#file-system EXT2FS # second extended file system (linux) > -#file-system LFS # log-structured file system > -#file-system NTFS# Windows/NT file system (experimental) > -#file-system CD9660 # ISO 9660 + Rock Ridge file system > -#file-system MSDOSFS # MS-DOS file system > -#file-system FDESC # /dev/fd > -#file-system KERNFS # /kern > -#file-system NULLFS # loopback file system > -#file-system OVERLAY # overlay file system > -#file-system PROCFS # /proc > -#file-system PUFFS # Userspace file systems (e.g. ntfs-3g & sshfs) > -#file-system SMBFS # experimental - CIFS; also needs nsmb (below) > -#file-system UMAPFS # NULLFS + uid and gid remapping > -#file-system UNION # union file system > -#file-system CODA# Coda File System; also needs vcoda (below) > -#file-system PTYFS # /dev/ptm support > +file-system EXT2FS # second extended file system (linux) > +file-system LFS # log-structured file system > +file-system NTFS# Windows/NT file system (experimental) > +file-system CD9660 # ISO 9660 + Rock Ridge file system > +file-system MSDOSFS # MS-DOS file system > +file-system FDESC # /dev/fd > +file-system KERNFS # /kern > +file-system NULLFS # loopback file system > +file-system OVERLAY # overlay file system > +file-system PROCFS # /proc > +file-system PUFFS # Userspace file systems (e.g. ntfs-3g & sshfs) > +file-system SMBFS # experimental - CIFS; also needs nsmb (below) > +file-system UMAPFS # NULLFS + uid and gid remapping > +file-system UNION # union file system > +file-system CODA# Coda File System; also needs vcoda (below) > +file-system PTYFS # /dev/ptm support > #file-system UDF # experimental - OSTA UDF CD/DVD file-system > #file-system HFS # experimental - Apple HFS+ (read-only) > #file-system NILFS # experime
Re: CVS commit: src/sys/arch/amd64/conf
On Mon, Aug 08, 2011 at 04:13:42PM +, Jonathan A. Kollasch wrote: > Module Name: src > Committed By: jakllsch > Date: Mon Aug 8 16:13:42 UTC 2011 > > Modified Files: > src/sys/arch/amd64/conf: GENERIC INSTALL > > Log Message: > Finish reverting premature modularization of amd64 kernels. Was this discussed somewhere? - Jukka.
Re: CVS commit: src/sys/arch/amd64/conf
On Mon, 21 Feb 2011 08:00:10 +, David Holland wrote: > Hmm -- adding a comment telling that the feature is experimental? Right now some of the things commented out in amd64 GENERIC are labeled experimental. Some of them are labeled "built as a module". Most of them aren't labeled at all. I think relying on that is not really a good idea, especially given that there often isn't a whole lot of extra space to use. Okay. > What would it bring to extend config(5) to express such a feature? Adding the syntax module options FOO module file-system PROCFS etc. would cost almost nothing and would make it clear exactly what's going on. It would also make it possible to build modules along with the kernel instead of as part of userland, which I think is desirable for a number of reasons. I see; I misunderstood your idea. I thought you wanted to add a specific "experimental" token :) Then, I agree. Although I am unsure on the semantic here: turning off a specific option (like "no module options FOO") implies: - don't build module, but allow it to be loaded explicitly (like "modload ./foo.kmod") - build module, but disallow autoload (with the correct word in its associated plist) - something else? > > 2. While not removing FFS and ELF support from GENERIC is a start, few > > of the other robustness concerns that have been brought up over the > > last two years have been addressed properly. > > > >- End users who are trying to diagnose a driver problem still > > will not be able to test -current by downloading and booting a > > kernel. They will need to also download and install a module > > set. This vastly increases the overhead and complexity of trying > > out -current and puts it past the reach of many newbies. This is > > a serious problem. > > This is more a matter of giving appropriate sets, or > installation/release media, rather than being modular/monolithic. To some extent. It should be possible for someone using a stable release to download and test-boot a nightly -current, without knowing much about the system and without having to install anything that's difficult or complicated to remove again. A monolithic kernel satisfies this requirement; so do other things, such as tarball kernels that include both a boot image and a module collection. However, the existing scheme we have doesn't serve. So it's mainly, from a user perspective, a matter of providing correct sets :) > Newbies do fine with Bubuntu/Linuxeries, and modules do live "happily" > there. Modules are also bound much more tightly to kernels in Linux. If you go install a new kernel package in any major Linux distribution you get an associated batch of modules with it; this happens transparently to the user. See above > Well, same goes for MONOLITHIC: turning off an option requires editing > config(5) file + kernel recompile. This requires "expert" > intervention... fetching src, building toolchain then kernel. Hum. Building a kernel might qualify as "advanced" but it's not "expert" in the sense I meant: formulating your own MONOLITHIC that works requires knowing quite a bit more about the system than just commenting out some lines in the kernel config does. This is one of the reasons the i386 MONOLITHIC was added. It's still not straightforward. Needs time, patience, when compared to a mere unlink. Plus, it doesn't solve the MONOLITHIC vs GENERIC issue: even if MONOLITHIC is proposed, issue is still there with third party modules. > How is that less/more expert than playing rm(1) in /stand? That will > seriously block autoloading. That does indeed block autoloading, but it's not an adequate solution because (1) it causes the nightly scripts to start whining (or at least I'd expect it to, I haven't tried specifically), and (2) it gets undone silently if you rebuild the world. Yup, the present system is not perfect; my proposal wasn't either anyway, but it's still the only quick and dirty way to do it, until it is properly fixed before -6 happens. > >- The versioning of installed modules is still restricted to one > > set per sys/param.h kernel version, and there's no way to tie a > > particular set of modules and a particular kernel together. This > > means that anyone working on broad kernel changes that affect > > module ABIs (e.g. me, but I'm hardly the only one) must in > > practice stick to monolithic configurations -- if any > > adjustment I make affects a module ABI I need to do a private > > sys/param.h bump and do a nearly full rebuild, instead of > > recompiling half a dozen files actually affected by the change. > > This is a non-starter; furthermore, in such an environment if I > > screw up with the versions I can easily render my test machine > > unbootable. > > 100% agreed. Regular problem with Xen kernels. Glad at least some
Re: CVS commit: src/sys/arch/amd64/conf
On Mon, Feb 21, 2011 at 12:20:14AM +0100, Jean-Yves Migeon wrote: > On 20.02.2011 22:58, David Holland wrote: > > 1. Traditionally, whether a driver/fs/option/whatever is listed in > > GENERIC is an indicator of how stable it's believed to be: entities > > that are missing are assumed not to work at all, entities that are > > commented out are assumed not to be stable, and only entities that are > > included and enabled by default are assumed to be production-ready. > > How would you specify a module option considered production-ready (hint: > zfs)? Traditionally, you don't; but, see the next section. > > This is a longstanding convention and it's wired into the built-in > > operating assumptions of many experienced sysadmins. There is now no > > way to tell which of the commented out entities are stable but meant > > to be used as modules and which of them are unstable/experimental or > > otherwise not ready yet. Having the stable drivers and other entities > > be present and uncommented in MONOLITHIC is not a good solution but > > it's the best currently available. (To solve this problem properly the > > config file syntax needs to be extended.) > > Hmm -- adding a comment telling that the feature is experimental? Right now some of the things commented out in amd64 GENERIC are labeled experimental. Some of them are labeled "built as a module". Most of them aren't labeled at all. I think relying on that is not really a good idea, especially given that there often isn't a whole lot of extra space to use. > What would it bring to extend config(5) to express such a feature? Adding the syntax module options FOO module file-system PROCFS etc. would cost almost nothing and would make it clear exactly what's going on. It would also make it possible to build modules along with the kernel instead of as part of userland, which I think is desirable for a number of reasons. > > 2. While not removing FFS and ELF support from GENERIC is a start, few > > of the other robustness concerns that have been brought up over the > > last two years have been addressed properly. > > > >- End users who are trying to diagnose a driver problem still > > will not be able to test -current by downloading and booting a > > kernel. They will need to also download and install a module > > set. This vastly increases the overhead and complexity of trying > > out -current and puts it past the reach of many newbies. This is > > a serious problem. > > This is more a matter of giving appropriate sets, or > installation/release media, rather than being modular/monolithic. To some extent. It should be possible for someone using a stable release to download and test-boot a nightly -current, without knowing much about the system and without having to install anything that's difficult or complicated to remove again. A monolithic kernel satisfies this requirement; so do other things, such as tarball kernels that include both a boot image and a module collection. However, the existing scheme we have doesn't serve. > Newbies do fine with Bubuntu/Linuxeries, and modules do live "happily" > there. Modules are also bound much more tightly to kernels in Linux. If you go install a new kernel package in any major Linux distribution you get an associated batch of modules with it; this happens transparently to the user. > >- There is still no way to avoid building modules you don't want, > > and while we have a start on a method to prevent autoloading > > them, it's not ready for prime time yet. Therefore, the only safe > > way to disable any functionality that's available as a module is > > to turn off "options MODULAR". This requires either expert > > attention or a maintained MONOLITHIC config. > > Well, same goes for MONOLITHIC: turning off an option requires editing > config(5) file + kernel recompile. This requires "expert" > intervention... fetching src, building toolchain then kernel. Hum. Building a kernel might qualify as "advanced" but it's not "expert" in the sense I meant: formulating your own MONOLITHIC that works requires knowing quite a bit more about the system than just commenting out some lines in the kernel config does. This is one of the reasons the i386 MONOLITHIC was added. > How is that less/more expert than playing rm(1) in /stand? That will > seriously block autoloading. That does indeed block autoloading, but it's not an adequate solution because (1) it causes the nightly scripts to start whining (or at least I'd expect it to, I haven't tried specifically), and (2) it gets undone silently if you rebuild the world. > >- The versioning of installed modules is still restricted to one > > set per sys/param.h kernel version, and there's no way to tie a > > particular set of modules and a particular kernel together. This > > means that anyone working on broad kernel changes that affect
Re: CVS commit: src/sys/arch/amd64/conf
On Sun, Feb 20, 2011 at 09:58:44PM +, David Holland wrote: > years without being solved. In fact, in general all such discussions > have been shouted down by module advocates insisting without evidence > that no such problems exist -- this is why these problems remain > unsolved and have been mostly receiving no further attention, and why > a large fraction of i386 developers simply use MONOLITHIC. What shouting? Can we please respect the work, intentions, and the design choices made by the port-i386 and port-amd64 maintainer himself. - Jukka.
Re: CVS commit: src/sys/arch/amd64/conf
On 20.02.2011 22:58, David Holland wrote: > 1. Traditionally, whether a driver/fs/option/whatever is listed in > GENERIC is an indicator of how stable it's believed to be: entities > that are missing are assumed not to work at all, entities that are > commented out are assumed not to be stable, and only entities that are > included and enabled by default are assumed to be production-ready. How would you specify a module option considered production-ready (hint: zfs)? > This is a longstanding convention and it's wired into the built-in > operating assumptions of many experienced sysadmins. There is now no > way to tell which of the commented out entities are stable but meant > to be used as modules and which of them are unstable/experimental or > otherwise not ready yet. Having the stable drivers and other entities > be present and uncommented in MONOLITHIC is not a good solution but > it's the best currently available. (To solve this problem properly the > config file syntax needs to be extended.) Hmm -- adding a comment telling that the feature is experimental? What would it bring to extend config(5) to express such a feature? > 2. While not removing FFS and ELF support from GENERIC is a start, few > of the other robustness concerns that have been brought up over the > last two years have been addressed properly. > >- End users who are trying to diagnose a driver problem still > will not be able to test -current by downloading and booting a > kernel. They will need to also download and install a module > set. This vastly increases the overhead and complexity of trying > out -current and puts it past the reach of many newbies. This is > a serious problem. This is more a matter of giving appropriate sets, or installation/release media, rather than being modular/monolithic. Newbies do fine with Bubuntu/Linuxeries, and modules do live "happily" there. >- There is still no way to avoid building modules you don't want, > and while we have a start on a method to prevent autoloading > them, it's not ready for prime time yet. Therefore, the only safe > way to disable any functionality that's available as a module is > to turn off "options MODULAR". This requires either expert > attention or a maintained MONOLITHIC config. Well, same goes for MONOLITHIC: turning off an option requires editing config(5) file + kernel recompile. This requires "expert" intervention... fetching src, building toolchain then kernel. Hum. How is that less/more expert than playing rm(1) in /stand? That will seriously block autoloading. >- The versioning of installed modules is still restricted to one > set per sys/param.h kernel version, and there's no way to tie a > particular set of modules and a particular kernel together. This > means that anyone working on broad kernel changes that affect > module ABIs (e.g. me, but I'm hardly the only one) must in > practice stick to monolithic configurations -- if any > adjustment I make affects a module ABI I need to do a private > sys/param.h bump and do a nearly full rebuild, instead of > recompiling half a dozen files actually affected by the change. > This is a non-starter; furthermore, in such an environment if I > screw up with the versions I can easily render my test machine > unbootable. 100% agreed. Regular problem with Xen kernels. > These issues have all been brought up repeatedly over the past two > years without being solved. In fact, in general all such discussions > have been shouted down by module advocates insisting without evidence > that no such problems exist -- this is why these problems remain > unsolved and have been mostly receiving no further attention, and why > a large fraction of i386 developers simply use MONOLITHIC. > > There is therefore no reason to think that any of these issues will be > resolved rapidly. The project needs to be able to continue to move > forward on other things until they are. > > Please at least set up a MONOLITHIC config. I would prefer, however, > if, instead, GENERIC was left as a monolithic config and a MODULAR > config was made available for testing. Committing GENERIC to be > modular can and should wait until the serious issues have been sorted > out and the module system is ready for production use. > > (I also question whether saving 1/16 of 0.1% of the typical RAM of a > not particularly beefy amd64 system is worth the complications of > dealing with modules.) Copy/pasting a mail I sent to Matthew: [...] Right; which one? i386. Curiously, I never heard of complains regarding the amd64 one, which is MODULAR. Now why is that? MONOLITHIC was added in a rush to shut up complaints, because people couldn't make a difference between these types: 1 - MONOLITHIC kernel, where options are compiled in (_provided_ you enabled them), with module support
Re: CVS commit: src/sys/arch/amd64/conf
On Sat, Feb 19, 2011 at 11:33:08AM +0200, Adam Hamsik wrote: > > 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. I object to *not* having a standard MONOLITHIC config for the following reasons: 1. Traditionally, whether a driver/fs/option/whatever is listed in GENERIC is an indicator of how stable it's believed to be: entities that are missing are assumed not to work at all, entities that are commented out are assumed not to be stable, and only entities that are included and enabled by default are assumed to be production-ready. This is a longstanding convention and it's wired into the built-in operating assumptions of many experienced sysadmins. There is now no way to tell which of the commented out entities are stable but meant to be used as modules and which of them are unstable/experimental or otherwise not ready yet. Having the stable drivers and other entities be present and uncommented in MONOLITHIC is not a good solution but it's the best currently available. (To solve this problem properly the config file syntax needs to be extended.) 2. While not removing FFS and ELF support from GENERIC is a start, few of the other robustness concerns that have been brought up over the last two years have been addressed properly. - End users who are trying to diagnose a driver problem still will not be able to test -current by downloading and booting a kernel. They will need to also download and install a module set. This vastly increases the overhead and complexity of trying out -current and puts it past the reach of many newbies. This is a serious problem. - There is still no way to avoid building modules you don't want, and while we have a start on a method to prevent autoloading them, it's not ready for prime time yet. Therefore, the only safe way to disable any functionality that's available as a module is to turn off "options MODULAR". This requires either expert attention or a maintained MONOLITHIC config. - The versioning of installed modules is still restricted to one set per sys/param.h kernel version, and there's no way to tie a particular set of modules and a particular kernel together. This means that anyone working on broad kernel changes that affect module ABIs (e.g. me, but I'm hardly the only one) must in practice stick to monolithic configurations -- if any adjustment I make affects a module ABI I need to do a private sys/param.h bump and do a nearly full rebuild, instead of recompiling half a dozen files actually affected by the change. This is a non-starter; furthermore, in such an environment if I screw up with the versions I can easily render my test machine unbootable. These issues have all been brought up repeatedly over the past two years without being solved. In fact, in general all such discussions have been shouted down by module advocates insisting without evidence that no such problems exist -- this is why these problems remain unsolved and have been mostly receiving no further attention, and why a large fraction of i386 developers simply use MONOLITHIC. There is therefore no reason to think that any of these issues will be resolved rapidly. The project needs to be able to continue to move forward on other things until they are. Please at least set up a MONOLITHIC config. I would prefer, however, if, instead, GENERIC was left as a monolithic config and a MODULAR config was made available for testing. Committing GENERIC to be modular can and should wait until the serious issues have been sorted out and the module system is ready for production use. (I also question whether saving 1/16 of 0.1% of the typical RAM of a not particularly beefy amd64 system is worth the complications of dealing with modules.) -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/arch/amd64/conf
On Sun, Feb 20, 2011 at 06:25:06PM +0200, Antti Kantee wrote: > On Sun Feb 20 2011 at 17:15:57 +0100, Jean-Yves Migeon wrote: > > => 1.3MiB. So, a total of 1.3M + 700k = 2MiB. Still missing 1.5MiB. > > MODULAR options seems to consume ~70kiB , so I would assume that the > > rest is due to PIC mode and ELF headers... ? > > Dunno where the space is going, but it's certainly not PIC overhead, > since the kernel or kernel modules are not PIC. The kernel modules will contain relocation info. For comparison you need to use 'size -A' (or similar) not ls. The amd64 objects may incluse the eh_frame section, kernel stuff should be compiled without that section. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/sys/arch/amd64/conf
On Sun Feb 20 2011 at 17:15:57 +0100, Jean-Yves Migeon wrote: > => 1.3MiB. So, a total of 1.3M + 700k = 2MiB. Still missing 1.5MiB. > MODULAR options seems to consume ~70kiB , so I would assume that the > rest is due to PIC mode and ELF headers... ? Dunno where the space is going, but it's certainly not PIC overhead, since the kernel or kernel modules are not PIC. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/sys/arch/amd64/conf
On 20.02.2011 15:45, matthew green wrote: >> 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). > > well, i dunno about others but i've found that the old modules > lying around tends to fill up space pretty quickly, but ignoring > that problem and looking at recent i386 builds, i see that the > MONOLITHIC kernel set is only 440kb larger than GENERIC, yet the > modules set is 3500kb. > > i didn't look into why, but there's some numbers to go from. (for i386) When I tried to use GENERIC as a replacement for MONOLITHIC for install floppies, I took a look at some of the duplication that happens between "filesys" and "builtin" modules. All in all, there are approx. ~700kiB of modules in /stand that are also accountable (e.g. "builtin") inside GENERIC. Taking the options(4) embedded inside MONOLITHIC and comparing them to their modules counterpart: - COMPAT_* => 400kiB as standalone modules - various fs => 720kiB - other options (PPP, accf_*, pseudo-devices): 200kiB => 1.3MiB. So, a total of 1.3M + 700k = 2MiB. Still missing 1.5MiB. MODULAR options seems to consume ~70kiB , so I would assume that the rest is due to PIC mode and ELF headers... ? That's still 1.5MiB bigger (a complete monolithic kernel vs a full-blown modular kernel). Needs to be xchecked though. Note that /stand also includes modules that cannot be included inside a monolithic kernel, like zfs and solaris compat layer. And these makes up for ~ half the size of /stand (5MiB). -- Jean-Yves Migeon jeanyves.mig...@free.fr
Re: CVS commit: src/sys/arch/amd64/conf
On Sun, Feb 20, 2011 at 07:19:03AM -0800, Paul Goyette wrote: > "...ignoring [the old modules] problem ..." > > A _single_ instance of modules on amd64 occupies > 11MB > > # du -sk dest/amd64/stand/amd64/5.99.46/ > 11404 dest/amd64/stand/amd64/5.99.46/ > # > > That's nearly as much as the total size of a GENERIC kernel (about 13MB > today). Interesting. Though as Jared and Antti already noted, there is a lot of duplication and some modules are built with debug information. A whole lot things are also only available as modules, which is kind of the whole point. A fair comparison would at least include those in the GENERIC. - Jukka.
re: CVS commit: src/sys/arch/amd64/conf
On Mon, 21 Feb 2011, matthew green wrote: well, i dunno about others but i've found that the old modules lying around tends to fill up space pretty quickly, but ignoring that problem and looking at recent i386 builds, i see that the MONOLITHIC kernel set is only 440kb larger than GENERIC, yet the modules set is 3500kb. i didn't look into why, but there's some numbers to go from. A bunch of those modules are also in GENERIC, what you're seeing is a lot of duplication.
Re: CVS commit: src/sys/arch/amd64/conf
On Sun Feb 20 2011 at 07:19:03 -0800, Paul Goyette wrote: > On Sun, 20 Feb 2011, Jukka Ruohonen wrote: > > >On Mon, Feb 21, 2011 at 01:45:01AM +1100, matthew green wrote: > >>well, i dunno about others but i've found that the old modules > >>lying around tends to fill up space pretty quickly, but ignoring > >>that problem and looking at recent i386 builds, i see that the > >>MONOLITHIC kernel set is only 440kb larger than GENERIC, yet the > >>modules set is 3500kb. > > > >This is not a real argument for or against. But the above shouldn't affect > >releases, which is after all the goal of any software project. If you track > >current, you are developing, or at least interested in the development, and > >in that case having modules outweight the potential or real space costs, > >IMO. > >You can always delete the modules, like you presumably delete old kernels > >too. > > "...ignoring [the old modules] problem ..." > > A _single_ instance of modules on amd64 occupies > 11MB > > # du -sk dest/amd64/stand/amd64/5.99.46/ > 11404 dest/amd64/stand/amd64/5.99.46/ > # > > That's nearly as much as the total size of a GENERIC kernel (about 13MB > today). I'll venture a guess that GENERIC doesn't include zfs compiled with -g. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/sys/arch/amd64/conf
On Sun, 20 Feb 2011, Jukka Ruohonen wrote: On Mon, Feb 21, 2011 at 01:45:01AM +1100, matthew green wrote: well, i dunno about others but i've found that the old modules lying around tends to fill up space pretty quickly, but ignoring that problem and looking at recent i386 builds, i see that the MONOLITHIC kernel set is only 440kb larger than GENERIC, yet the modules set is 3500kb. This is not a real argument for or against. But the above shouldn't affect releases, which is after all the goal of any software project. If you track current, you are developing, or at least interested in the development, and in that case having modules outweight the potential or real space costs, IMO. You can always delete the modules, like you presumably delete old kernels too. "...ignoring [the old modules] problem ..." A _single_ instance of modules on amd64 occupies > 11MB # du -sk dest/amd64/stand/amd64/5.99.46/ 11404 dest/amd64/stand/amd64/5.99.46/ # That's nearly as much as the total size of a GENERIC kernel (about 13MB today). - | 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/amd64/conf
On Mon, Feb 21, 2011 at 01:45:01AM +1100, matthew green wrote: > well, i dunno about others but i've found that the old modules > lying around tends to fill up space pretty quickly, but ignoring > that problem and looking at recent i386 builds, i see that the > MONOLITHIC kernel set is only 440kb larger than GENERIC, yet the > modules set is 3500kb. This is not a real argument for or against. But the above shouldn't affect releases, which is after all the goal of any software project. If you track current, you are developing, or at least interested in the development, and in that case having modules outweight the potential or real space costs, IMO. You can always delete the modules, like you presumably delete old kernels too. For the record, being involved in driver development, I tend to load as much as possible from rc.local(5). The productivity gains are immense. The same goes for rump(3), albeit for slightly different reasons. - Jukka.
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). well, i dunno about others but i've found that the old modules lying around tends to fill up space pretty quickly, but ignoring that problem and looking at recent i386 builds, i see that the MONOLITHIC kernel set is only 440kb larger than GENERIC, yet the modules set is 3500kb. i didn't look into why, but there's some numbers to go from. .mrg.
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/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/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
