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