Re: config(5) break down
2010/3/15 Wojciech A. Koszek wkos...@freebsd.org: device X builds device X staticly into the kernel (and maybe does something device-specific), while: module X Only builds a KLD. I picked module, since it seems to be more-or-less an oposite of: static X which could build feature X, which is not a device staticly. I think your config(8) has this problem solved somehow, since you seem to have filesystem keyword as well. Nowadays, given that as you mentioned for NetBSD, in FreeBSD we also have no scoping for config(8), we must build all KLDs just in case someone needs them, since we don't know which file belongs to which module. Who writes these in what file? I was wondering how does Linux/Solaris kernel build system work in terms of opt_*.h files? Do they have some alternative solutions for #ifdef's based on what has been included into the kernel at configuration time? Without looking them, I don't think any infrastructural (== config(1) itself) change helps. Why not fix source code rather than improving config(1)? Masao
Re: config(5) break down
On Mon, Mar 15, 2010 at 11:50:09PM +0900, Masao Uebayashi wrote: [...] Without looking them, I don't think any infrastructural (== config(1) You know, saying stuff like without looking at [this], or i haven't read any of [that], while honest, is not a very good way of leading a conversation. People might just think you're condescending. itself) change helps. Why not fix source code rather than improving config(1)? Because, like it or not, config(1) has to change, because autoconf(9) has to change, too. I know it's not part of your own agenda, but it's a fact. Now, you can choose to dismiss any opinion that includes a change in config(1), but you might also want to think about how changing config(1) could help you. If some people are going to change it anyway, why wouldn't you consider the benefits of adding changes that serve your agenda? -- Quentin Garnier - c...@cubidou.net - c...@netbsd.org See the look on my face from staying too long in one place [...] every time the morning breaks I know I'm closer to falling KT Tunstall, Saving My Face, Drastic Fantastic, 2007. pgp4nfzzfgTl8.pgp Description: PGP signature
Re: config(5) break down
On Sun, 14 Mar 2010, Wojciech A. Koszek wrote: I was wondering how does Linux/Solaris kernel build system work in terms of opt_*.h files? Do they have some alternative solutions for #ifdef's based on what has been included into the kernel at configuration time? It's been a while since I poked around with Linux, but I think they have a single file that contains all that info. Solaris has no config. Period. You don't have any opt_*.h files. And you don't really need them. It's a fully dynamic kernel so the only things you can set are things like DEBUG and LOCKDEBUG. You don't worry about including specific modules, because they are all compiled separately and loaded on demand. Loading of modules is driven by config files in /etc that define what module is responsible for a specific device type (e.g. a specific PCI vendor and device ID combination.) Of course, if those config files get corrupted then the machine is unbootable. To recover you must boot from install media and likely reinstall the OS. And since everything is compiled separately you can often just replace one module with another one that is compiled with DEBUG turned on. Without rebooting the machine. (Certain inter-module interfaces are affected by DEBUG while others are not. YMMV.) Eduardo
Re: config(5) break down
On Tue, Mar 16, 2010 at 1:57 AM, Eduardo Horvath e...@netbsd.org wrote: On Sun, 14 Mar 2010, Wojciech A. Koszek wrote: I was wondering how does Linux/Solaris kernel build system work in terms of opt_*.h files? Do they have some alternative solutions for #ifdef's based on what has been included into the kernel at configuration time? It's been a while since I poked around with Linux, but I think they have a single file that contains all that info. My understanding is splitting opt_*.h into small files is just only to save rebuild time. Is this right? It's also same as GNU Autoconf + configure + #include config.h do. Solaris has no config. Period. You don't have any opt_*.h files. And you don't really need them. It's a fully dynamic kernel so the only things you can set are things like DEBUG and LOCKDEBUG. You don't worry about including specific modules, because they are all compiled separately and loaded on demand. Loading of modules is driven by config files in /etc that define what module is responsible for a specific device type (e.g. a specific PCI vendor and device ID combination.) Of course, if those config files get corrupted then the machine is unbootable. To recover you must boot from install media and likely reinstall the OS. Ah. Thanks for explaining this. This is pretty much expected. And this is what NetBSD should not be, IMO, because - one of NetBSD's targets is highly customized embedded purposes - let users customize as they want - NetBSD is free, unlike QNX. - users are not stupid - but those customized binaries are not supported And since everything is compiled separately you can often just replace one module with another one that is compiled with DEBUG turned on. Without rebooting the machine. (Certain inter-module interfaces are affected by DEBUG while others are not. YMMV.) Thanks, and this is also pretty much expected too. IIRC Windows did similar thing; providing foo.dll foodbg.dll. I think this strategy (== providing normal+debug binaries as official module binaries) would work for us too. Masao
Re: config(5) break down
On Tue, Mar 16, 2010 at 6:55 AM, Masao Uebayashi uebay...@gmail.com wrote: And this is what NetBSD should not be, IMO, because - one of NetBSD's targets is highly customized embedded purposes - let users customize as they want - NetBSD is free, unlike QNX. - users are not stupid - but those customized binaries are not supported Let me clarify: - NetBSD is used for many purposes. - The official binary should choose the sane default - FFS_EI enabled by default - XIP would be disabled by default - While leave developers freedom to customize NetBSD more. Masao
Re: config(5) break down
On Mon, Mar 15, 2010 at 10:08 PM, Masao Uebayashi uebay...@gmail.com wrote: Let me clarify: - NetBSD is used for many purposes. - The official binary should choose the sane default - FFS_EI enabled by default - XIP would be disabled by default - While leave developers freedom to customize NetBSD more. Err, no. BOTH developers and users should have the freedom to customize NetBSD, not only developers. And, of course, users should not have to rebuild anything, ever. If we can't provide such a binary-friendly system, we have failed as developers. And it's possible to provide such a system, as has been proven by Solaris, Windows and, increasingly, Linux. (That doesn't mean developers shouldn't have the ability to rebuild from source. Of course they should, that's the joy of open source! But being open source is not an excuse to provide a system that cannot be customized when distributed in binary form. Otherwise, that's no different than the no documentation because you can read the source policy...) -- Julio Merino
Re: config(5) break down
Julio Merino wrote: On Mon, Mar 15, 2010 at 10:08 PM, Masao Uebayashi uebay...@gmail.com wrote: Let me clarify: - NetBSD is used for many purposes. - The official binary should choose the sane default - FFS_EI enabled by default - XIP would be disabled by default - While leave developers freedom to customize NetBSD more. Err, no. BOTH developers and users should have the freedom to customize NetBSD, not only developers. And, of course, users should not have to rebuild anything, ever. If we can't provide such a binary-friendly system, we have failed as developers. And it's possible to provide such a system, as has been proven by Solaris, Windows and, increasingly, Linux. So what are you saying here? That our goal is to be like Solaris, Windows and Linux? What is the point in that? There already exist several systems (as you note) who are that. Do you expect NetBSD to be in that same segment? Just curious about what people think/want here... Johnny -- Johnny Billquist || I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip - B. Idol
Re: config(5) break down
On Tue, Mar 16, 2010 at 06:55:36AM +0900, Masao Uebayashi wrote: On Tue, Mar 16, 2010 at 1:57 AM, Eduardo Horvath e...@netbsd.org wrote: On Sun, 14 Mar 2010, Wojciech A. Koszek wrote: I was wondering how does Linux/Solaris kernel build system work in terms of opt_*.h files? Do they have some alternative solutions for #ifdef's based on what has been included into the kernel at configuration time? It's been a while since I poked around with Linux, but I think they have a single file that contains all that info. My understanding is splitting opt_*.h into small files is just only to save rebuild time. Is this right? It's also same as GNU Autoconf + configure + #include config.h do. I think it is also for narrowing the impact of particular options; it tends to act as a sort of layering and encapsulation. And saves a bit of confusion when a commiter enabled his debugging facility with DEBUG, which may not be unique. And since everything is compiled separately you can often just replace one module with another one that is compiled with DEBUG turned on. Without rebooting the machine. (Certain inter-module interfaces are affected by DEBUG while others are not. YMMV.) Thanks, and this is also pretty much expected too. IIRC Windows did similar thing; providing foo.dll foodbg.dll. I think this strategy (== providing normal+debug binaries as official module binaries) would work for us too. You mean that the delivery of two versions of each kernel module could eventually solve the problem for you? -- Wojciech A. Koszek wkos...@freebsd.org http://FreeBSD.czest.pl/~wkoszek/
