Re: config(5) break down
On Tue, Mar 16, 2010 at 05:26:20AM +, David Holland wrote: After a fashion. Check how our LOCKDEBUG works. :-/ You mean crawls? Martin
Re: config(5) break down
On Tue, Mar 16, 2010 at 06:22:14AM +0100, Wojciech A. Koszek wrote:
You mean that you have a solution for:
struct mystruct {
#ifdef DEBUG_MYSTRUCT
int line;
char*file;
char*func;
void*another_pointer;
#endif
...
};
within a kernel code? That's the simpliest example, of course. There are
areas where you simply can't prevent this kind of #ifdef's.
Yes: don't code like that. :-)
That's not to say it doesn't happen because there is a culture
of using #ifdef to deal with things that should be taken care of at
runtime, and to optimize things that don't need optimizing.
Old habits are hard to break.
Re: config(5) break down
On Tue, Mar 16, 2010 at 06:42:29AM +0100, Wojciech A. Koszek wrote: coming from the same build and with the same set of critical options. Otherwise, if the struct mutex changes its size due to #define LOCK_DEBUGGING in the kernel, you'll going to get a page fault from the module's code with a useless trace message. FYI, that's not a problem for NetBSD. The ABI is insensitive to things like DIAGNOSTIC/DEBUG/LOCKDEBUG/-g/whatever. By design because it caused so much hassle in the past with userspace tools and was one of the major pain points with LKMs.
Re: config(5) break down
Julio Merino wrote: On Mon, Mar 15, 2010 at 11:22 PM, Johnny Billquist b...@softjar.se wrote: 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? I never said that. But last I read, NetBSD has never been targeted exclusively to people working on embedded systems. Hmm. So you mean that the only other group is embedded systems? No, you never said that NetBSD should be Linux, Windows or Solaris, you only used those as reference points on what could/should be done. The that's a fine difference. 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? I expect NetBSD to be as flexible as reasonably possible with the binaries we distribute. If we have to tell any user rebuild the software with option foo to get what they want, we have failed at that. And most users will run away. I would dare say that any user who decided to try NetBSD would cease use it, and not because of the build-you-own-kernel reason, but for the simple fact that there are a lot of alternatives out there which better fulfills his needs. The most important one being a lot of commercial or semi-commercial programs which don't run, or run poorly on NetBSD. So yes, most people are already running away. And the config system and kernel building isn't the reason. Let's instead ask us who, and why, some people do drift over to NetBSD? I would say that a large portion of those are people who for some reason or other have gotten tired of the magical modules, autoconfiguration, and magic tools that manage the system for you, and who wants to have better control and understanding of the system. Or else, who are curious about alternative ways of doing things, or possibly curious about how Unix systems used to do it. Thus, a big change to the philosophy of NetBSD here means we still would not attract the random users, but we would drive away the small following we do have. But hey. That is just my opinion, and I don't have any hard facts to back them up. Again, what I meant is: providing the source code of any application is not an excuse to having a deficient design that does not allow extensibility or customization without rebuilding. And that's orthogonal to being Solaris or whatever. But sometimes things do clash. I'm not against solutions that extend and refine what NetBSD do, but I do think it's the wrong way to try to redefine the system. And especially doing so with the argument that others do it that way. But, as I've said a number of times, I'm an old fart who is very conservative and backwards. Heck, I even run NetBSD on my VAXen, although I have not gone past NetBSD 3... Johnny
NetBSD binary [was Re: config(5) break down]
could you please use subject lines that somewhat reflect the content of the discussion please? I was surprised to find a discussion like this under that subject, or maybe you want to sneak it through? :) On Tue, Mar 16, 2010 at 11:39:07AM +0100, Johnny Billquist wrote: Julio Merino wrote: (...) I expect NetBSD to be as flexible as reasonably possible with the binaries we distribute. If we have to tell any user rebuild the software with option foo to get what they want, we have failed at that. And most users will run away. Well, if you tell them, run this script and reboot to configure your system for your needs, then most users would sign that. And that's all our (cross-)building is. Run a script. Now if the source is not properly maintained because someone keeps yelling we need binary kernel modules that don't install using said script... or build time options turn over to bitrot because you could as well keep and load all the relevant code... well, that's when NetBSD fails. but ... I would dare say that any user who decided to try NetBSD would cease use it, and not because of the build-you-own-kernel reason, but for the simple fact that there are a lot of alternatives out there which better fulfills his needs. The most important one being a lot of commercial or semi-commercial programs which don't run, or run poorly on NetBSD. Absolutely. That's the #1 reason linux guys who are initially quite charmed with NetBSD go away again. Hey! We don't have flash, skype, ... (and don't tell me about our emulator stuff. It's neat but it's not really a solution to the problem) So yes, most people are already running away. And the config system and kernel building isn't the reason. Actually the experience I had with my NetBSD advocacy in the windows and linux circles I used to do that was that everybody was quite positively impressed about the clarity of kernel config files, documentation and building. Let's instead ask us who, and why, some people do drift over to NetBSD? I would say that a large portion of those are people who for some reason or other have gotten tired of the magical modules, autoconfiguration, and magic tools that manage the system for you, and who wants to have better control and understanding of the system. Or else, who are curious about alternative ways of doing things, or possibly curious about how Unix systems used to do it. Absolutely! Thanks for these wise words, johnny. -Martin
Re: DTrace FBT provider heads-up
Darran Hunt wrote: Hi all, I've committed the Function Boundary Trace provider to NetBSD current. This DTrace provider automatically instruments every function in the kernel with an entry and exit probe. The probes have true zero-probe effect (i.e. they don't affect the system when disabled), as they don't actually exist in the code until they're enabled. When enabled a probe directly patches the function to add a jump into FBT provider at the function's entry or exit points. This gives us over 29,000 instrumentation points available for tracing with DTrace. The full argument list is passed to the probe on function entry, and the return result is passed on exit. More info available here: http://docs.sun.com/app/docs/doc/817-6223/chp-fbt?a=view Amazing work! Thanks, Darren
Re: NetBSD binary [was Re: config(5) break down]
On Tue, 16 Mar 2010, Martin S. Weber wrote: Well, if you tell them, run this script and reboot to configure your system for your needs, then most users would sign that. And that's all our (cross-)building is. Run a script. Now if the source is not properly maintained because someone keeps yelling we need binary kernel modules that don't install using said script... or build time options turn over to bitrot because you could as well keep and load all the relevant code... well, that's when NetBSD fails. but ... I find that config and modules are at cross purposes. Config gives you the luxury of customizing the compilation process. Modules should allow you to replace indivcual binaries independent of the rest of the kernel. If I can't use a module someone else compiled without having to reconfigure and rebuild my kernel I fail to comprehend the purpose of having a modular kernel. If you want to reduce the kernel memory footprint, compile a custom kernel with only the code you want and you save yourself the overhead of the kernel linker and binary (in most cases ELF) headers and linkage goo. If you want to add functionality at runtime, we've had LKMs for a long time. With a modular kernel that uses config you not only need to build a custom kernel with information about what devices exist on the machine, but you also get the opportunity to lose the code at runtime. (Oops! I copied over a new kernel but forgot to copy over /modules!) Eduardo
Re: config(5) break down
2010/3/16 Julio Merino j...@netbsd.org: 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 I'm wholeheartedly behind Julio's statement. Users should never have to rebuild anything. And as Julio stated in the past, this applies to pkgsrc aswell, where we recently did a major step forward with pkgin. Zafer.
Re: NetBSD binary [was Re: config(5) break down]
Let's instead ask us who, and why, some people do drift over to NetBSD? I would say that a large portion of those are people who for some reason or other have gotten tired of the magical modules, autoconfiguration, and magic tools that manage the system for you, and who wants to have better control and understanding of the system. Absolutely! Thanks for these wise words, johnny. What they said. Thank you, Johnny, for putting it so eloquently. This is very much what bothers me about the directions NetBSD is headed, and has for quite a while: it appears to be trying to turn itself into Yet Another Unix Variant, different from Linux and Solaris and their ilk only in the brand name on the case. People say things like we'll never win over the Linux users without $FEATURE!, which makes me say why do you want to?. If I want Linux - or Solaris, or any of various other Unices - I know where to find it; if NetBSD succeeds in turning into a Linux - or whatever - clone, it will have lost the reasons it previously gave me to prefer it. But we're not trying to do that! Enough of you are that that's NetBSD's direction. You're trying to come up with point-and-drool installers. You're trying to fully support desktop environments. You're trying to make system administration easy for non-sysadmins. You are, in short, trying to give it the things I picked NetBSD to get away from, the things Johnny summarized so well: lots of magic code doing things users are not only not expected to understand but are expected to not understand (and under whose hood prying is not supported). /etc/rc.d/*. Modular kernels. Sysinst. build.sh. I don't want a system that has any code under whose hood prying is not supported; if the answer to I'm having trouble with $FOO is messing with $FOO is not supported; use our magic code instead, that's a bug as far as I'm concerned. I've seen it called elitist to prefer, for example, installing by hand. I can understand that point of view, but I think it misses the point fairly fundamentally. It's the difference between inclusive and exclusive - I don't want to keep hoi polloi out by demanding understanding before they are worthy to (say) install NetBSD; rather, I want to bring them in by imparting that understanding, with things like manual installation serving as teaching (and self-testing) tools. Nothing teaches like experience. Yes, this excludes the people who don't understand and don't want to. To steal a term from marketing, I don't think NetBSD should try to serve that market segment; it's already well-served by others, and I see no percentage in trying to join them. It doesn't serve them better (indeed, by adding yet another alternative they neither are nor want to be competent to choose among, it serves them worse) and it doesn't serve NetBSD (people who don't even want to understand are among the least likely to turn into developers and contribute back). So what's to like? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: MI overrides of bus_dma(9), bus_space(9), pci(9)
On Mar 11, 2010, at 3:41 PM, David Young wrote: On Thu, Mar 11, 2010 at 12:58:30PM -0800, Matt Thomas wrote: On Mar 11, 2010, at 12:31 PM, David Young wrote: On Thu, Mar 11, 2010 at 12:20:41PM -0800, Matt Thomas wrote: On Mar 11, 2010, at 11:40 AM, David Young wrote: Resource management: PCI-* bridges can override bus_space_alloc(9)/bus_space_free(9) in order to (1) allocate space from the upstream bus, (2) widen/narrow its I/O- or memory-space window. Then we can provide a reliable rbus-like facility to detachable buses through bus_space(9). bus_dma_subregion can be used for that. So bus_space_subregion. Matt, How do we open the windows? I don't see a reason to do that but you could allocate new larger subregions from the parent. Let's say that we have this PCI setup: Host-PCI bridge: forwards MMIO 0xff00-0x to PCI bus | pci0 | + - - - | PCI-PCI bridge: forwards MMIO in [0x-0x] to secondary | pci1 | ++---+ || | PCI-CardBus bridge IDE controller video adapter | ++ || cardbus0 cardbus1 || || || NIC NIC The BIOS has exclusively assigned MMIO regions to each PCI adapter. It may or may not have assigned a range to the CardBus bridge itself. It has probably not reserved space for the CardBus NICs, especially not if they were attached after boot-up. We have to exclusively assign MMIO space to each CardBus NIC's registers. If the PCI-PCI bridge does not forward an address range that is big enough to fit the NICs' registers, then we have to reprogram the bridge to forward a wider range. Dave Since PPB/CBB allocates in 1 MB units, that seems unlikely unless no MEM resources have been alloacted at all. However I think bus_space(9) needs a bus_space_alloc_tag which will allocates like bus_space_alloc but returns that space in its own bus_space tag which can be used to allocate pieces of that allocated region. We'd also need a bus_space_free_tag.
Re: config(5) break down
At Tue, 16 Mar 2010 10:22:42 +, Andrew Doran a...@netbsd.org wrote: Subject: Re: config(5) break down Correctamundo. 95% of downloads in the week following the release of 5.0 were for x86. It doesn't say much about embedded but does tell us that a very large segment of the user population does commodity hardware. (What the figures also revealed was that a number of the ports had as close to zero downloads as matters. Which is, to be frank, a red flag for those that are not maintained.) Please do not even think about using downloads as a measure of which ports are used and how much they are used! That's a completely invalid measurement of how NetBSD might be used. Many of us just download the source. We don't tell you which parts of it that we use or don't use. Even port-* mailing list subscriptions aren't a truly valid hint of which ports are used or how much they are used. -- Greg A. Woods Planix, Inc. wo...@planix.com +1 416 218 0099http://www.planix.com/ pgpVTS2ubXFh7.pgp Description: PGP signature
Re: config(5) break down
On Tue, Mar 16, 2010 at 03:18:10PM -0400, Greg A. Woods wrote: Please do not even think about using downloads as a measure of which ports are used and how much they are used! That's a completely invalid measurement of how NetBSD might be used. No kidding. We'll ship thousands of units of products with NetBSD firmware on them in the next year. I doubt we download more than one or two copies of NetBSD a month, for miscellaneous use on developers' machines -- if that. I don't care what's done in NetBSD to make fancy all-singing, all-dancing desktop installations nicer *SO LONG AS IT DOESN'T GET IN MY WAY*. Bloating up the base system's libraries so I have to do more customization gets in my way. Making kernel configurations like I use a pain in the butt to keep working gets in my way. Lots of other things people want to do in NetBSD to support desktop use don't, and some are even positive for me. Please consider that many different user populations do many different things with NetBSD when proposing major changes, and I can't see how we cannot manage to sustain those many different populations in the future. But bogus justifications involving who downloads what built binary releases from the FTP server are not really helpful to anyone. Thor
[no subject]
On Mon, 15 Mar 2010, Aleksej Saushev wrote: While here, can anyone enlighten us how one boots NetBSD so that it looks for modules in non-default directory? You can't, and the people who want NetBSD to move to modular kernels don't seem to care. Until this problem is fixed, I will try to avoid using modular kernels. --apb (Alan Barrett)
Re: config(5) break down
On Tue, Mar 16, 2010 at 06:50:29PM +0100, Zafer Aydo?an wrote: I'm wholeheartedly behind Julio's statement. Users should never have to rebuild anything. Er, why? Users should never have to perform complex unautomated procedures, because such procedures can easily be screwed up and recovery becomes difficult or impossible. But recompiling things isn't a complex unautomated procedure, it's a complex automated procedure, and not really that much different from other complex automated procedures like binary updates. Nor is it necessarily slow; building a kernel doesn't take any longer than booting Vista... -- David A. Holland dholl...@netbsd.org
Re: NetBSD binary [was Re: config(5) break down]
Dear participants in this thread, If you feel the need to share your general opinions about NetBSD or the direction of development, please continue this on the netbsd-us...@netbsd.org mailing list. Please respect the users which have subscribed to the tech- mailing lists to participate in technical, specific and solution-oriented discussions. Many thanks and best regards, Mark Weinem
Unsafe GENERIC? - Re: (unknown)
Alan Barrett a...@cequrux.com writes: On Mon, 15 Mar 2010, Aleksej Saushev wrote: While here, can anyone enlighten us how one boots NetBSD so that it looks for modules in non-default directory? You can't, and the people who want NetBSD to move to modular kernels don't seem to care. Until this problem is fixed, I will try to avoid using modular kernels. Well... Could we arrange it so that we have safe monolithic GENERIC until issues are resolved somehow? It isn't nice to provide highly experimental feature as default one. Until release management is arranged so that drivers are backported faster, users of commodity hardware are forced to use current sometimes. -- HE CE3OH...
Re: Unsafe GENERIC? - Re: (unknown)
On Tue, 16 Mar 2010, Aleksej Saushev wrote: Well... Could we arrange it so that we have safe monolithic GENERIC until issues are resolved somehow? For i386, use MONOLITHIC instad of GENERIC For amd64, the default is still MONOLITHIC, if I remember correctly. - | Paul Goyette | PGP DSS 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: Unsafe GENERIC? - Re: (unknown)
Paul Goyette p...@whooppee.com writes: On Tue, 16 Mar 2010, Aleksej Saushev wrote: Well... Could we arrange it so that we have safe monolithic GENERIC until issues are resolved somehow? For i386, use MONOLITHIC instad of GENERIC For amd64, the default is still MONOLITHIC, if I remember correctly. This produces unnecessary confusion and nothing more. Update procedure becomes more machine-dependent. Even on commodity hardware, where some users prefer to stay with i386 because of e.g. WINE and other 32-bit only software. -- HE CE3OH... pgpWIWokP0FMi.pgp Description: PGP signature
Kernel modules in non-default directories
On Tuesday 16 March 2010 20:51:23 Alan Barrett wrote: On Mon, 15 Mar 2010, Aleksej Saushev wrote: [how to boot] NetBSD so that it looks for modules in non-default directory? You can't [...] Is this problem specific to NetBSD? Do other operating systems provide solutions? Best, Mark
Re: Kernel modules in non-default directories
Mark Weinem mark.wei...@alumni.uni-due.de writes: On Tuesday 16 March 2010 20:51:23 Alan Barrett wrote: On Mon, 15 Mar 2010, Aleksej Saushev wrote: [how to boot] NetBSD so that it looks for modules in non-default directory? You can't [...] Is this problem specific to NetBSD? Do other operating systems provide solutions? Yes, FreeBSD allows selecting directory where kernel and modules reside. -- HE CE3OH...
