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 | +--+--++
