Re: remove any unwanted devices from the kernel.
Nick Holland wrote: The biggest reasons to do this are because you have too much time on your hands, and you want to impress people by having things break, then you swoop in to rescue everyone from your fabricated disaster. Actually I think most people do it because you are tought to do so with both Linux and FreeBSD. Just like people who come from a windows environment try to download a package from the providers website rather than install the package provided by the OS/Distro/whatever. # Han
Re: remove any unwanted devices from the kernel.
On Fri, 6 Jun 2008 16:50:37 -0700 Scott Learmonth [EMAIL PROTECTED] wrote: As someone else who writes code for this fine os would say: removing drivers is pure masturbation. Hah, perfect. As a first foray into BSD I stumbled upon FreeBSD. To make it do what I wanted, step one was to compile a custom kernel. BOOYAH, I got a geek-on. A few months later I had chosen OpenBSD, and have never looked back. Sure, tinkering is what we do in may ways (n00b or dev, computer guts are what we like), and what better tinker-tool than 5 minutes picking drivers and a 3 hour compile? But you know what? GENERIC just works. And the REALLY beautiful thing, is that config just works too for kernel configuration. You can even write your changes to the kernel permanently, saving all that compile time. I'm not versed enough to know if a config modified kernel provides the same, um, savings as a custom kernel if you used it to remove drivers however. Cheers I had an incident with a 4.1+ snapshot where in order to get some customer config to work I needed to build a GENERIC OBSD system from scratch with some patch code. This was only somewhat more complicated than building a custom FreeBSD kernel. The monolithic OBSD build methodology is only good most of the time, and when it isn't, it's a bit of a bear. Dhu
Re: remove any unwanted devices from the kernel.
* Jon [EMAIL PROTECTED] [2008-06-06 03:04]: Why would someone want to do this? because it is plain boring to just use GENERIC. fiddling with your kernel, you can waste a lot of time to get it to compile, then brag about that over beer with your friends, and while they keep drinking your pager alerts you back because your kernel crashed, since you also like to play with compiler optimization levels. While you are allowed to play more iwth your kernel, your friends just sit somewhere and drink, what a choice. After a while you don't have friends any more, but a custom kernel that boots 3 seconds faster than GENERIC and is stable for some time. Certainly worth it. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: remove any unwanted devices from the kernel.
* Geoff Steckel [EMAIL PROTECTED] [2008-06-06 12:55]: For systems which must boot very quickly, removing unused drivers whose probe routines cause significant timeouts can make a big difference. bullshit. config -ef /bsd and disable device does it nicely. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: remove any unwanted devices from the kernel.
* Ted Unangst [EMAIL PROTECTED] [2008-06-06 16:05]: On 6/6/08, Jordi Beltran Creix [EMAIL PROTECTED] wrote: Then what is the meaning of this comment in the kernel's memcpy? A few kbs don't matter, yet a dozen bytes do? /* * This is designed to be small, not fast. */ That comment comes from a time when memory cost ten bucks a byte. We don't necessarily keep all the comments up to date with the current market prices, though, figuring anybody reading kernel comments is moderately rational. Apparently not. there's also a difference between code that is actually being used versus dead code. keeping code in use small helps the caches. having unused code doesn't really hurt after boot. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: remove any unwanted devices from the kernel.
Sometimes it matters to be small and sometimes fast. That is a decision made by the kernel hacker. Joe user does not make these decisions because he/she does not understand the overall impact. As someone else who writes code for this fine os would say: removing drivers is pure masturbation. On Fri, Jun 06, 2008 at 06:05:06PM +0900, Jordi Beltran Creix wrote: Then what is the meaning of this comment in the kernel's memcpy? A few kbs don't matter, yet a dozen bytes do? /* * This is designed to be small, not fast. */ 2008/6/6, Nick Holland [EMAIL PROTECTED]: Jon wrote: I usually name the kernel to the machine hostname, but you can give it any name. Edit the kernel config file: Remove any hardware related options that are not relevant to your machine. http://www.muine.org/~hoang/openpf.html#customize Why would someone want to do this? Is this nothing more than saving a negligible amount of memory? The biggest reasons to do this are because you have too much time on your hands, and you want to impress people by having things break, then you swoop in to rescue everyone from your fabricated disaster. See, computers are supposed to be unreliable and impossible to understand and take lots of effort just to keep running and such. If they Just Work, you haven't proven anything other than your skill at careful design and planning, People don't appreciate that, they much prefer to see you in action. Heroes rescue people from obvious danger, they don't avoid problems proactively. Hey, if you gotta encourage them out onto the ledge so you can be a hero, whatever. Fortunately, most computer people would rather be fighting with existing computer systems than planning avoiding future problems or documenting things. After all, it's not the quality of job that counts, it's the effort people see you putting into it. Any fool can put up a website and say anything they want. Just because you saw it on the 'net doesn't make it true. After that crap of an introduction, I'm not going to bother reading the rest of what this person has to say. See FAQ5 for the official line on this topic. (alternate response: a few k here, a few k there, soon you are still talking about nothing of significance...) Nick.
Re: remove any unwanted devices from the kernel.
On Fri, Jun 06, 2008 at 06:05:06PM +0900, Jordi Beltran Creix wrote: Then what is the meaning of this comment in the kernel's memcpy? A few kbs don't matter, yet a dozen bytes do? GENERIC has different constraints than install kernels or boot code. We use the same memcpy in all three. -Otto
Re: remove any unwanted devices from the kernel.
Then what is the meaning of this comment in the kernel's memcpy? A few kbs don't matter, yet a dozen bytes do? /* * This is designed to be small, not fast. */ 2008/6/6, Nick Holland [EMAIL PROTECTED]: Jon wrote: I usually name the kernel to the machine hostname, but you can give it any name. Edit the kernel config file: Remove any hardware related options that are not relevant to your machine. http://www.muine.org/~hoang/openpf.html#customize Why would someone want to do this? Is this nothing more than saving a negligible amount of memory? The biggest reasons to do this are because you have too much time on your hands, and you want to impress people by having things break, then you swoop in to rescue everyone from your fabricated disaster. See, computers are supposed to be unreliable and impossible to understand and take lots of effort just to keep running and such. If they Just Work, you haven't proven anything other than your skill at careful design and planning, People don't appreciate that, they much prefer to see you in action. Heroes rescue people from obvious danger, they don't avoid problems proactively. Hey, if you gotta encourage them out onto the ledge so you can be a hero, whatever. Fortunately, most computer people would rather be fighting with existing computer systems than planning avoiding future problems or documenting things. After all, it's not the quality of job that counts, it's the effort people see you putting into it. Any fool can put up a website and say anything they want. Just because you saw it on the 'net doesn't make it true. After that crap of an introduction, I'm not going to bother reading the rest of what this person has to say. See FAQ5 for the official line on this topic. (alternate response: a few k here, a few k there, soon you are still talking about nothing of significance...) Nick.
Re: remove any unwanted devices from the kernel.
On 2008-06-06, Jordi Beltran Creix [EMAIL PROTECTED] wrote: Then what is the meaning of this comment in the kernel's memcpy? A few kbs don't matter, yet a dozen bytes do? It depends where the bytes are. If they're not optional and are somewhere that needs to fit on *all* install media for *all* arch, sure a dozen bytes matters.
Re: remove any unwanted devices from the kernel.
Sometimes it matters to be small and sometimes fast. That is a decision made by the kernel hacker. Joe user does not make these decisions because he/she does not understand the overall impact. As someone else who writes code for this fine os would say: removing drivers is pure masturbation. Oh dear I think that ye all do protest far too much. Threats of unspecified system instability are hard to believe. I strongly suggest that anyone desiring to optimize things should be pointed at tools to monitor and profile system performance before doing any changes at all, not just kernel mangling. Hacking out chunks of kernel code because it isn't used is clearly a bad idea. On the other hand, removing unused I/O device drivers has been done for many decades in many O/Ss. It's not a task for the uninitiated but it should not be fraught with danger. I suggest that there are reasonable cases where a non-core-team person would correctly want to remove unused drivers. For systems which must boot very quickly, removing unused drivers whose probe routines cause significant timeouts can make a big difference. Sometimes timeouts are the only way to check for an I/O device behind a blind interface. For instance, checking a floppy drive's seek time is a significant wait. For systems which are intended to run with little memory or which are straining at architectural limits, 100K here and 100K there can make quite a big difference in what applications can run. Many drivers are over 150K when linked. When a megabyte or two counts, removing 10 drivers could make a big difference. If the kernel code is well structured, the following must be true: Removing a driver which is essential to normal operation must cause the kernel compile or link stage to fail. Secret, undocumented dependencies (neither in the man pages or in the source code comments) between apparently unrelated modules are very serious bugs. - The x86 architecture and I/O devices are seriously flawed. There are cases where it is not obvious which driver is the correct one for a peripheral, and the order in which devices are probed is critical. Self identifying devices such as on the PCI bus are mostly immune from this problem, and the kernel is quite good about announcing a PCI device for which no driver is found. Still, ISA devices can be a minefield. While removing an ISA driver has potential to recover the most space or time, it's the hardest to verify. Unfortunately the biggest payback is often from removing drivers intended for systems not made in 10 years or more. - As an aside, I've been wondering what the heck named is doing to initialize itself. It does many thousands of disk accesses for no visible benefit and takes a very long time to do them. curmudgeonly geoff steckel
Re: remove any unwanted devices from the kernel.
On 6/6/08 6:52 AM, Geoff Steckel [EMAIL PROTECTED] wrote: Sometimes it matters to be small and sometimes fast. That is a decision made by the kernel hacker. Joe user does not make these decisions because he/she does not understand the overall impact. As someone else who writes code for this fine os would say: removing drivers is pure masturbation. I suggest that there are reasonable cases where a non-core-team person would correctly want to remove unused drivers. Reasonable, maybe, corner cases, more likely than not. For systems which must boot very quickly, removing unused drivers whose probe routines cause significant timeouts can make a big difference. Sometimes timeouts are the only way to check for an I/O device behind a blind interface. For instance, checking a floppy drive's seek time is a significant wait. This sounds like a corner case, how many times is this going to have and effect on Joe User? For systems which are intended to run with little memory or which are straining at architectural limits, 100K here and 100K there can make quite a big difference in what applications can run. Many drivers are over 150K when linked. When a megabyte or two counts, removing 10 drivers could make a big difference. This is not the type of project that Joe User is going to be working on. It is the type of project that is going to go into the hands (hopefully) of a programmer or systems engineer who has the knowledge to do the diagnostics when something goes wrong building this system. This sounds like another corner case to me. If the kernel code is well structured, the following must be true: Removing a driver which is essential to normal operation must cause the kernel compile or link stage to fail. It does, at least in my experience. I was that young and stupid person who believed it was a badge of honor to run a custom kernel, now I believe it is a badge of honor to get your system functioning with the least effort expended, which is one of the reasons I have come to enjoy running OpenBSD. As an aside, I've been wondering what the heck named is doing to initialize itself. It does many thousands of disk accesses for no visible benefit and takes a very long time to do them. I have never noticed a problem with this, and my DNS servers aren't exactly on top end hardware. In fact, they are on 300MHz machines that were rescued from the dumpster... If it is something that annoys you, why don't you do some profiling of the startup routine and see what you can optimize? Tim
Re: remove any unwanted devices from the kernel.
On 6/6/08, Jordi Beltran Creix [EMAIL PROTECTED] wrote: Then what is the meaning of this comment in the kernel's memcpy? A few kbs don't matter, yet a dozen bytes do? /* * This is designed to be small, not fast. */ That comment comes from a time when memory cost ten bucks a byte. We don't necessarily keep all the comments up to date with the current market prices, though, figuring anybody reading kernel comments is moderately rational. Apparently not.
Re: remove any unwanted devices from the kernel.
On 6/6/08, Geoff Steckel [EMAIL PROTECTED] wrote: Threats of unspecified system instability are hard to believe. http://marc.info/?l=openbsd-miscm=109088660014351w=2 For systems which must boot very quickly, removing unused drivers whose probe routines cause significant timeouts can make a big difference. Sometimes timeouts are the only way to check for an I/O device behind a blind interface. For instance, checking a floppy drive's seek time is a significant wait. introducing config. You're compiling your own kernel, so you must have read the man page for config, right? So you know there's no reason to actually compile anything, right? For systems which are intended to run with little memory or which are straining at architectural limits, 100K here and 100K there can make quite a big difference in what applications can run. Many drivers are over 150K when linked. When a megabyte or two counts, removing 10 drivers could make a big difference. Given the cost of hardware today, the fraction of total memory that one megabyte represents, and the nature of any job that needs all your memory, by the time you finish compiling that kernel it's going to need two megabytes more, not just one. And then what? If the kernel code is well structured, the following must be true: Removing a driver which is essential to normal operation must cause the kernel compile or link stage to fail. What compiler are you using that can detect your system's hardware for you?
Re: remove any unwanted devices from the kernel.
That comment comes from a time when memory cost ten bucks a byte. We don't necessarily keep all the comments up to date with the current market prices, though, figuring anybody reading kernel comments is moderately rational. Apparently not. Well, according to previous answers, the 25 years old comment was actually justified, but if it weren't, style(9) would come to mind. Been eating your own dog food lately? If we understand that custom kernels are unsupported, that some kernel options can be modified without recompiling, and that some changes could have security implications, why do you care? Do you have to kill a kitten each time we build a custom kernel? Two if we actually tinker with the code? Maybe you should close the source, then.
Re: remove any unwanted devices from the kernel.
Jordi Beltran Creix wrote: Well, according to previous answers, the 25 years old comment was actually justified, but if it weren't, style(9) would come to mind. Been eating your own dog food lately? If we understand that custom kernels are unsupported, that some kernel options can be modified without recompiling, and that some changes could have security implications, why do you care? Do you have to kill a kitten each time we build a custom kernel? Two if we actually tinker with the code? Maybe you should close the source, then. Did you really completely miss the point, which is that they couldn't care less what you do with your kernel, as long as you modify it with _zero_ anticipation or expectation of the slightest bit of support? Because the FAQ, this thread, and numerous other threads exactly like it has made that abundantly clear to me and apparently most everyone else, yet people still come around crying foul when they get jumped on for asking for help with (or why they should/shouldn't build) their custom-built kernels.
Re: remove any unwanted devices from the kernel.
On Fri, 6 Jun 2008 10:14:55 -0400 Ted Unangst [EMAIL PROTECTED] wrote On 6/6/08, Geoff Steckel [EMAIL PROTECTED] wrote: For systems which must boot very quickly, removing unused drivers whose probe routines cause significant timeouts can make a big difference. Sometimes timeouts are the only way to check for an I/O device behind a blind interface. For instance, checking a floppy drive's seek time is a significant wait. introducing config. You're compiling your own kernel, so you must have read the man page for config, right? So you know there's no reason to actually compile anything, right? Yes, there is. Applying config multiple times to a built system is much harder to maintain over versions and releases than tracking cvs of GENERIC, files.xxx, etc. and applying diff3/merging, which is scriptable. For systems which are intended to run with little memory or which are straining at architectural limits, 100K here and 100K there can make quite a big difference in what applications can run. Many drivers are over 150K when linked. When a megabyte or two counts, removing 10 drivers could make a big difference. Given the cost of hardware today, the fraction of total memory that one megabyte represents, and the nature of any job that needs all your memory, by the time you finish compiling that kernel it's going to need two megabytes more, not just one. And then what? Hm... Maybe you should look up the concept transaction cost. Changing hardware, especially multiple installations, can be expensive, disallowed, or impossible. In those cases the cost of adding memory is essentially infinite. Some platforms cannot add memory at any cost. The advantage of being able to run even for a few months more on existing hardware can be very large. The advantage of using a smaller hardware platform and saving (say) two watts of power can multiply to hundreds of dollars or even the possibility of a project at all. If the kernel code is well structured, the following must be true: Removing a driver which is essential to normal operation must cause the kernel compile or link stage to fail. What compiler are you using that can detect your system's hardware for you? I think we had already determined that the user removing drivers is reasonably well informed, especially about the details of the platforms to use the kernel. I'm speaking to any entanglements between drivers or with apparently hardware-independent functionality, etc. geoff steckel
Re: remove any unwanted devices from the kernel.
The people reading the faq are not the people who need custom kernels. Those people *know* what they need and are not deterred. But as always, when we try to help the userbase by offering the advice they need, someone needs to chime in and muddy the waters. So now some dude is going to read your email and conclude that he can get better mysql speed on his 1gb box by shaving a driver. You're not doing anyone any favors. And no, we cannot assume that people correctly self identify when they are special. Ignorant people don't know they are ignorant. But at least some of them read the faq. So at least let them get the best answer for them. On Jun 6, 2008, at 2:17 PM, Geoff Steckel [EMAIL PROTECTED] wrote: On Fri, 6 Jun 2008 10:14:55 -0400 Ted Unangst [EMAIL PROTECTED] wrote On 6/6/08, Geoff Steckel [EMAIL PROTECTED] wrote: For systems which must boot very quickly, removing unused drivers whose probe routines cause significant timeouts can make a big difference. Sometimes timeouts are the only way to check for an I/O device behind a blind interface. For instance, checking a floppy drive's seek time is a significant wait. introducing config. You're compiling your own kernel, so you must have read the man page for config, right? So you know there's no reason to actually compile anything, right? Yes, there is. Applying config multiple times to a built system is much harder to maintain over versions and releases than tracking cvs of GENERIC, files.xxx, etc. and applying diff3/merging, which is scriptable. For systems which are intended to run with little memory or which are straining at architectural limits, 100K here and 100K there can make quite a big difference in what applications can run. Many drivers are over 150K when linked. When a megabyte or two counts, removing 10 drivers could make a big difference. Given the cost of hardware today, the fraction of total memory that one megabyte represents, and the nature of any job that needs all your memory, by the time you finish compiling that kernel it's going to need two megabytes more, not just one. And then what? Hm... Maybe you should look up the concept transaction cost. Changing hardware, especially multiple installations, can be expensive, disallowed, or impossible. In those cases the cost of adding memory is essentially infinite. Some platforms cannot add memory at any cost. The advantage of being able to run even for a few months more on existing hardware can be very large. The advantage of using a smaller hardware platform and saving (say) two watts of power can multiply to hundreds of dollars or even the possibility of a project at all. If the kernel code is well structured, the following must be true: Removing a driver which is essential to normal operation must cause the kernel compile or link stage to fail. What compiler are you using that can detect your system's hardware for you? I think we had already determined that the user removing drivers is reasonably well informed, especially about the details of the platforms to use the kernel. I'm speaking to any entanglements between drivers or with apparently hardware-independent functionality, etc. geoff steckel
Re: remove any unwanted devices from the kernel.
As someone else who writes code for this fine os would say: removing drivers is pure masturbation. Hah, perfect. As a first foray into BSD I stumbled upon FreeBSD. To make it do what I wanted, step one was to compile a custom kernel. BOOYAH, I got a geek-on. A few months later I had chosen OpenBSD, and have never looked back. Sure, tinkering is what we do in may ways (n00b or dev, computer guts are what we like), and what better tinker-tool than 5 minutes picking drivers and a 3 hour compile? But you know what? GENERIC just works. And the REALLY beautiful thing, is that config just works too for kernel configuration. You can even write your changes to the kernel permanently, saving all that compile time. I'm not versed enough to know if a config modified kernel provides the same, um, savings as a custom kernel if you used it to remove drivers however. Cheers
remove any unwanted devices from the kernel.
I usually name the kernel to the machine hostname, but you can give it any name. Edit the kernel config file: Remove any hardware related options that are not relevant to your machine. http://www.muine.org/~hoang/openpf.html#customize Why would someone want to do this? Is this nothing more than saving a negligible amount of memory?
Re: remove any unwanted devices from the kernel.
2008/6/5 Jon [EMAIL PROTECTED]: I usually name the kernel to the machine hostname, but you can give it any name. Edit the kernel config file: Remove any hardware related options that are not relevant to your machine. http://www.muine.org/~hoang/openpf.html#customize Why would someone want to do this? Is this nothing more than saving a negligible amount of memory? People do this mostly to feel good about themselves. But, yes, removing stuff saves a few kB. There is also the thinking that removing unnecessary stuff makes the system more secure. This latter approach is more pertinent to a modular kernel such as the Linux kernel. OpenBSD, of course, uses a classical monolithic kernel. Let it be known that user-customized OBSD kernels are unsupported by the developers. Do it only if you have a very good reason to do so (activate a software feature or to get some special h/w to work). /juan
Re: remove any unwanted devices from the kernel.
On 6/5/08, Jon [EMAIL PROTECTED] wrote: I usually name the kernel to the machine hostname, but you can give it any name. Edit the kernel config file: Remove any hardware related options that are not relevant to your machine. http://www.muine.org/~hoang/openpf.html#customize Why would someone want to do this? Is this nothing more than saving a negligible amount of memory? I recommend reading the real FAQ: http://www.openbsd.org/faq/faq5.html#Why
Re: remove any unwanted devices from the kernel.
Jon wrote: I usually name the kernel to the machine hostname, but you can give it any name. Edit the kernel config file: Remove any hardware related options that are not relevant to your machine. http://www.muine.org/~hoang/openpf.html#customize Why would someone want to do this? Is this nothing more than saving a negligible amount of memory? The biggest reasons to do this are because you have too much time on your hands, and you want to impress people by having things break, then you swoop in to rescue everyone from your fabricated disaster. See, computers are supposed to be unreliable and impossible to understand and take lots of effort just to keep running and such. If they Just Work, you haven't proven anything other than your skill at careful design and planning, People don't appreciate that, they much prefer to see you in action. Heroes rescue people from obvious danger, they don't avoid problems proactively. Hey, if you gotta encourage them out onto the ledge so you can be a hero, whatever. Fortunately, most computer people would rather be fighting with existing computer systems than planning avoiding future problems or documenting things. After all, it's not the quality of job that counts, it's the effort people see you putting into it. Any fool can put up a website and say anything they want. Just because you saw it on the 'net doesn't make it true. After that crap of an introduction, I'm not going to bother reading the rest of what this person has to say. See FAQ5 for the official line on this topic. (alternate response: a few k here, a few k there, soon you are still talking about nothing of significance...) Nick.
