Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
On Sat, Mar 29, 2008 at 9:21 PM, Jacob Meuser [EMAIL PROTECTED] wrote: On Sat, Mar 29, 2008 at 12:58:40PM -0400, Douglas A. Tutty wrote: On Sat, Mar 29, 2008 at 11:00:01AM +0200, Lars Nood??n wrote: ... using the GENERIC kernel ... 2) One thing that may not be visible enough is that config(8) can be used to modify kernel parameters without needing to recompile. That gives you a fair amount of customization without deviating from the GENERIC configuration. It is possible to make modifications to the currently running kernel as well as to save these changes in the form of a new kernel binary so that the changes stay even after system restarts. One thing I'm not clear on: if the only issue is kernel size based on having an old box with low memory, where every MB counts, does deactivating unnecessary drivers with config actually result in a smaller kernel or just a kernel with deactivated drivers? Shrinking the kernel would be the only reason I would have of touching the kernel as I'm not into trying out experimental features. It would be too bad if config doesn't do this. if your machine is low enough on ram that you would even consider recompiling a kernel, just to save ram, it's time to retire the machine. I'd disagree VERY strongly there,... there are LOTS of low spec (yet industrial tolerance) hardware appliances out there (and I spend almost my entire live working on this kind of hardware. The malleability and source availability of the free UNIX-like systems is what allows one to use these platforms in the first place. Imagine trying to get Microsoft or Sun to produce an OS for you that runs on a 486dx100?
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
On Sun, Mar 30, 2008 at 9:26 PM, Jacob Meuser [EMAIL PROTECTED] wrote: you say, config makes me boot faster. so then people go and config their kernel, and then we get problem reports about broken kernels. that's fine if you want to go break your machines. don't try telling others to do the same. I disagree,... this form of knowledge sharing amongst more advanced users of any OS should be encouraged. Perhaps there is merit in it in a wider context,... we wont know unless such things are discussed and debated. Simply poh pohing it out of hand without wider discussion throughout the user base is foolish at best.
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
On Mon, Mar 31, 2008 at 09:47:09AM +0200, Ross Cameron wrote: On Sun, Mar 30, 2008 at 9:26 PM, Jacob Meuser [EMAIL PROTECTED] wrote: you say, config makes me boot faster. so then people go and config their kernel, and then we get problem reports about broken kernels. that's fine if you want to go break your machines. don't try telling others to do the same. I disagree,... this form of knowledge sharing amongst more advanced users of any OS should be encouraged. Perhaps there is merit in it in a wider context,... we wont know unless such things are discussed and debated. Simply poh pohing it out of hand without wider discussion throughout the user base is foolish at best. please learn to use the archives before saying whether or not something has been/needs to be discussed. -- [EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
On Mon, Mar 31, 2008 at 09:39:33AM +0200, Ross Cameron wrote: On Sat, Mar 29, 2008 at 9:21 PM, Jacob Meuser [EMAIL PROTECTED] wrote: On Sat, Mar 29, 2008 at 12:58:40PM -0400, Douglas A. Tutty wrote: On Sat, Mar 29, 2008 at 11:00:01AM +0200, Lars Nood??n wrote: ... using the GENERIC kernel ... 2) One thing that may not be visible enough is that config(8) can be used to modify kernel parameters without needing to recompile. That gives you a fair amount of customization without deviating from the GENERIC configuration. It is possible to make modifications to the currently running kernel as well as to save these changes in the form of a new kernel binary so that the changes stay even after system restarts. One thing I'm not clear on: if the only issue is kernel size based on having an old box with low memory, where every MB counts, does deactivating unnecessary drivers with config actually result in a smaller kernel or just a kernel with deactivated drivers? Shrinking the kernel would be the only reason I would have of touching the kernel as I'm not into trying out experimental features. It would be too bad if config doesn't do this. if your machine is low enough on ram that you would even consider recompiling a kernel, just to save ram, it's time to retire the machine. I'd disagree VERY strongly there,... there are LOTS of low spec (yet industrial tolerance) hardware appliances out there (and I spend almost my entire live working on this kind of hardware. great. you know what you're doing (presumably). this discussion is not about such hardware, nor about such situations. the thing is, if you do such things, you _BETTER_ know what you're doing, because you are on your own. do not expect help from here. and definitely _DO NOT_ try to hide that you have made such modifications when you post bug reports. The malleability and source availability of the free UNIX-like systems is what allows one to use these platforms in the first place. Imagine trying to get Microsoft or Sun to produce an OS for you that runs on a 486dx100? there are distros based on OpenBSD specifically for such purposes. discussions about tweaking your kernel for such situations are probably much more acceptable there. I think people don't comprehend how small the OpenBSD developer community is compared to, oh, let's say linux. -- [EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
Ross Cameron [EMAIL PROTECTED] writes: On Sun, Mar 30, 2008 at 9:26 PM, Jacob Meuser [EMAIL PROTECTED] wrote: you say, config makes me boot faster. so then people go and config their kernel, and then we get problem reports about broken kernels. that's fine if you want to go break your machines. don't try telling others to do the same. I disagree,... this form of knowledge sharing amongst more advanced users of any OS should be encouraged. Yes, and the knowledge among the more advanced users is don't do it. So that's what's being shared. Perhaps there is merit in it in a wider context,... we wont know unless such things are discussed and debated. Simply poh pohing it out of hand without wider discussion throughout the user base is foolish at best. Oh, really. And you think that we haven't discussed this for the past 10 years? all over the mailing lists. //art
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
On Mon, Mar 31, 2008 at 3:47 AM, Ross Cameron [EMAIL PROTECTED] wrote: On Sun, Mar 30, 2008 at 9:26 PM, Jacob Meuser [EMAIL PROTECTED] wrote: you say, config makes me boot faster. so then people go and config their kernel, and then we get problem reports about broken kernels. that's fine if you want to go break your machines. don't try telling others to do the same. I disagree,... this form of knowledge sharing amongst more advanced users of any OS should be encouraged. Unfortunately, a lot of !advanced users will also experiment, and then come back with it's broken, fix it. For advanced users who like to tinker, OpenBSD's support model is /usr/src/. Unfortunately, too many people who think they can mangle config means that they are advanced (l)users. Perhaps there is merit in it in a wider context,... we wont know unless such things are discussed and debated. Simply poh pohing it out of hand without wider discussion throughout the user base is foolish at best. In my experience, it's simply a matter of experience and resources, and the OpenBSD project as a whole is very unhappy with supporting users who insist on playing with ooo, shiny, I need another 1% of performance, or I can get my kernel down to 3,467,296 bytes with stupid kernel tricks! It all boils down to the old doctor, doctor, it hurts when I do that joke. OpenBSD is just being proactive in telling the users 'don't do that'. On the other hand, people like you do have legitimate needs, and it's up to the developers to see if they can support you. -- http://www.glumbert.com/media/shift http://www.youtube.com/watch?v=tGvHNNOLnCk This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation. Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted. -- Gene Spafford learn french: http://www.youtube.com/watch?v=j1G-3laJJP0feature=related
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
On Sun, Mar 30, 2008 at 02:58:38PM -0400, scott wrote: I believe it was mentioned aways back in the message stream, but perhaps it's worth reconsidering at this juncture... Keep the low emi/rfi 386 machine user-proximity but convert it to an X server with the more capable X client (app server) machine farther away. Sure that suggestion was made. Currently, the X server is my Athlon64 and is 60 feet away from my wife and its still too close. I have been given a dual P-133 Tyan board which will become the application/file/whatever server and we'll see how close to it my wife can be once I get it set up in a good steel case (I'm looking at addtronics steel cases since this board is Baby-AT). I'll save the Athlon box for things that only it can do conveniently (editing or retouching picture, watching DVDs, graphical web-browsing). Note that none of my old boxes are low enough in RAM to need a custom kernel. The Tyan board will take a max of 512 MB (8 x 64 MB EDO ECC SIMMS) once I get them. My IBM 486 takes 4 x 32 MB once I get them. The biggest issue is boot drives: I may be using CF cards for boot and then adding a scsi card to the Tyan and use SCSI drives for the data archive. Doug.
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
Douglas A. Tutty wrote: ... Shrinking the kernel would be the only reason I would have of touching the kernel as I'm not into trying out experimental features. It would be too bad if config doesn't do this... Nick Holland wrote: config strictly deactivates the drivers, it doesn't reduce memory consumption or disk footprint. ... Digressing slightly into config and what's in the FAQ regarding why or why not to deviate from GENERIC... Using config to modify the GENERIC kernel's settings can apparently improve boot speed. So maybe config should be mentioned in section 5.6 of the FAQ, Why do I need a custom kernel? to steer those wondering about improving boot time away from trying unnecessarily to create a custom kernel. e.g. for B' 5.6, Why do I need a custom kernel? Removing device drivers may speed the boot process on your system, but can complicate recovery should you have a hardware problem, and is very often done wrong. config can be used instead of re-compiling to modify kernel parameters and speed booting. See the section of the config(8) man page on kernel modification Since OpenBSD uses a monolithic kernel, it is outside the ability of config to physically remove the deactivated drivers. ... That could also be useful to have in the FAQ somewhere. It's explicit in the kernel's nature, but could be mentioned for those who miss the ramifications of using a monolithic kernel. Removing drivers for reduced memory is really a for advanced users only task, and you VERY QUICKLY run into diminishing returns. That can be emphasized more heavily by moving forward one sentence in section 5.6, and adding that in. e.g. for the very start of B' 5.6: Actually, you probably don't. Only the most advanced and knowledgeable users with the most demanding applications need to worry about a customized kernel or system, and even then you very quickly run into diminishing returns. Regards, -Lars
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
On Sun, Mar 30, 2008 at 01:04:09PM +0300, Lars Nood??n wrote: Douglas A. Tutty wrote: ... Shrinking the kernel would be the only reason I would have of touching the kernel as I'm not into trying out experimental features. It would be too bad if config doesn't do this... Nick Holland wrote: config strictly deactivates the drivers, it doesn't reduce memory consumption or disk footprint. ... Digressing slightly into config and what's in the FAQ regarding why or why not to deviate from GENERIC... Using config to modify the GENERIC kernel's settings can apparently improve boot speed. So maybe config should be mentioned in section 5.6 of the FAQ, Why do I need a custom kernel? to steer those wondering about improving boot time away from trying unnecessarily to create a custom kernel. e.g. for B' 5.6, Why do I need a custom kernel? Removing device drivers may speed the boot process on your system, but can complicate recovery should you have a hardware problem, and is very often done wrong. config can be used instead of re-compiling to modify kernel parameters and speed booting. See the section of the config(8) man page on kernel modification Since OpenBSD uses a monolithic kernel, it is outside the ability of config to physically remove the deactivated drivers. ... That could also be useful to have in the FAQ somewhere. It's explicit in the kernel's nature, but could be mentioned for those who miss the ramifications of using a monolithic kernel. Removing drivers for reduced memory is really a for advanced users only task, and you VERY QUICKLY run into diminishing returns. That can be emphasized more heavily by moving forward one sentence in section 5.6, and adding that in. e.g. for the very start of B' 5.6: Actually, you probably don't. Only the most advanced and knowledgeable users with the most demanding applications need to worry about a customized kernel or system, and even then you very quickly run into diminishing returns. I know that on a regular i386 machine, its far easier to add a bit of ram than to fitz with the kernel. I had seen on this list a while ago someone needing to fitz with the kernel for putting OBSD on some imbedded device. He (she?) wasn't building on the imbedded device, just wanted to pare down memory usage as much as possible. So perhaps to add to this entry for the FAQ, something that address this desire to shrink the kernel to save memory: ... For standard i386 old computers with little ram, recompiling the kernel does not provide enough free memory to affect what you can then do with that old computer. You are far better to just add a bit more ram. I know that other distros have dropped actual 386 CPUs from their supported list so that i386 actually needs minimum 486. The reasoning I've heard is that the amount of memory required is too much for any remaining actual 386 boxes to actually have. I know that my old PS/2 Model 70-A21 was a 386 with 4 MB Ram (at $1K per MB) and I think it could take a maximum 16 MB (but my memory from 1988 is very fuzzy). Where there any 386 boxes that could take 32MB ram, and do any still exist? Doug.
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
I believe it was mentioned aways back in the message stream, but perhaps it's worth reconsidering at this juncture... Keep the low emi/rfi 386 machine user-proximity but convert it to an X server with the more capable X client (app server) machine farther away. -Original Message- From: Douglas A. Tutty [EMAIL PROTECTED] To: misc misc@openbsd.org Subject: Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD) Date: Sun, 30 Mar 2008 13:12:57 -0400 Mailer: Mutt/1.5.13 (2006-08-11) Delivered-To: [EMAIL PROTECTED] On Sun, Mar 30, 2008 at 01:04:09PM +0300, Lars Nood??n wrote: Douglas A. Tutty wrote: I know that other distros have dropped actual 386 CPUs from their supported list so that i386 actually needs minimum 486. The reasoning I've heard is that the amount of memory required is too much for any remaining actual 386 boxes to actually have. I know that my old PS/2 Model 70-A21 was a 386 with 4 MB Ram (at $1K per MB) and I think it could take a maximum 16 MB (but my memory from 1988 is very fuzzy). Where there any 386 boxes that could take 32MB ram, and do any still exist? Doug.
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
On Sun, Mar 30, 2008 at 01:04:09PM +0300, Lars Nood?n wrote: Using config to modify the GENERIC kernel's settings can apparently improve boot speed. So maybe config should be mentioned in section 5.6 of the FAQ, Why do I need a custom kernel? to steer those wondering about improving boot time away from trying unnecessarily to create a custom kernel. no, for the same reason that people should not recompile a kernel. you might end up disabling something you need. Lars, the FAQ, this list, they are really for people who need help, not for people to tweak their machines for silly reasons. you say, config makes me boot faster. so then people go and config their kernel, and then we get problem reports about broken kernels. that's fine if you want to go break your machines. don't try telling others to do the same. -- [EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
Douglas A. Tutty wrote: ... So perhaps to add to this entry for the FAQ, something that address this desire to shrink the kernel to save memory: ... For standard i386 old computers with little ram, recompiling the kernel does not provide enough free memory to affect what you can then do with that old computer. You are far better to just add a bit more ram. much closer to something I'd consider adding. :) I know that other distros have dropped actual 386 CPUs from their supported list so that i386 actually needs minimum 486. The reasoning I've heard is that the amount of memory required is too much for any remaining actual 386 boxes to actually have. Same thing was done recently with OpenBSD, actually. There are better reasons, however... The big one was the 80386 was a first generation 32 bit processor for Intel, and there were a lot of ugly work-arounds in the OpenBSD kernel for 80386 systems that didn't need to be there for 80486 and later systems. Dropping support for the 80386 simplified the kernel code, and as we know, that's a very good thing. There were some practical reasons why you don't want to use OpenBSD on an 80386 system: 1) OpenBSD /requires/ a hardware FPU. The 80386 chip did not have it, you needed to add-on an 80387 Math coprocessor, and a relatively small number of 80386 machines had this. 2) There are things we just do today that were big deals back in the 80386 and before days, simple little things like compressing a file. Simply loading an 80386 system with OpenBSD was an all-day affair, due mostly to the time required to uncompress the *.tgz files! 3) IDE disks were not common on 80386 systems. You don't want to try to install OpenBSD on an MFM or ESDI drive. Even what should have been an easy retrofit was complicated by inflexible BIOSs. 4) 16M RAM was almost unheard of back then...and many of the 80386 systems of the day were using different RAM than more modern systems do, so the likelihood that you had an OpenBSD-capable 80386 was very low, and upgrading it to being OpenBSD-capable was cost-prohibitive. When this was done, no one had been sending in 80386 dmesg's for a long time. Even before then...the 80386 code spent some time broken around the 3.3 days..and only a couple people had even noticed (we didn't even realize it wasn't broke machines until we realized that several people were seeing the exact same problem!). I know that my old PS/2 Model 70-A21 was a 386 with 4 MB Ram (at $1K per MB) and I think it could take a maximum 16 MB (but my memory from 1988 is very fuzzy). Where there any 386 boxes that could take 32MB ram, and do any still exist? oh, most certainly. The VERY FIRST generation of non-IBM-brand 80386 (i.e., Zenith, Compaq, AST, etc.) systems were basically 80286 systems with a faster processor and almost everything else carried over from the 80286 siblings. However, by the time the second generation rolled around, the systems were starting to make use of the 80386 potential (though the OS and apps were still treating the 80386 as a really, really fast 8088, for the most part. I'm most familiar with the Zenith systems, as that's where I was at the time, but the second generation Zenith 80386 systems were capable of 20M on board (supposed to be 32M, but a bug was found with support for actual production 4M 72 pin SIMMs (which didn't even exist when the machine was first shipped!) that limited their use to only the lower four slots, so limit was 20M, though later boards fixed that and were able to use all 32M. I recall no customers complaining about this bug. :) I've got several of these second generation Zenith machines still, one of which was, according to the dmesg log, the last systems to run OpenBSD on an 80386. I also have a no-name clone board which I'd put 8x4M 30 pin SIMMs in for 32M, as well. By the time I had the resources to do this, I'd long got and retired much better machines that were capable of running OpenBSD. I'd actually be surprised if the IBM Model 70 was design limited to 16M, though it is likely there was just no physical way to put more than that in. The PS/2 MCA machines were much more advanced than the ISA-standard machines of the day, though a pain in the butt to work with and incompatable, but I'm pretty sure all 32 bits of address lines made it out to the bus. HOWEVER, the 80386sx was a non-starter for a long time: these machines only had 24 bit address buses, so it had a max of 16M, and being they were cheap machines, the actual potential of most of the hardware they were used in was 12M, 8M, or way, way less. I don't know that I have ever seen an 80387SX chip -- kinda bizarre thing, an expensive accelerator for a machine you bought because you didn't need much speed... Nick.
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
On Sun, Mar 30, 2008 at 11:04:34PM -0400, Nick Holland wrote: HOWEVER, the 80386sx was a non-starter for a long time: these machines only had 24 bit address buses, so it had a max of 16M, and being they were cheap machines, the actual potential of most of the hardware they were used in was 12M, 8M, or way, way less. I don't know that I have ever seen an 80387SX chip -- kinda bizarre thing, an expensive accelerator for a machine you bought because you didn't need much speed... I think it more likely that most people bought the 386SX because they didn't have much money rather than they didn't need much speed. That's certainly the reason I and a couple of friends did. There was also the 80386SL variation which used less power and was particularly good for laptops. As it happens I bought three 80387SL FP co-processors, for my Toshiba T3300SL laptop, for my desktop and one as a Christmas gift. It made a huge difference in number-crunching times. (The 80387SL seems to have replaced the 387SX rather early.) The laptop dual-booted DOS and COHERENT, a commercial 16-bit UNIX-like operating system. When there were no readily-available 32-bit OSs, the 386SX/SL processors seemed to make sense. No good reason for them later... Emilio
configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
... using the GENERIC kernel ... I'll answer because I floated a poorly framed question like this one earlier. The second part of my answer is probably more useful. 1) A lot of thought and planning goes into the GENERIC kernel and the final arrangement is a source of pride. So if it's matter of trusting the code then it is still possible, if you have the time, resources or skill, to do your own code audit and still have a GENERIC kernel. Staying with the GENERIC configuration allows your feedback regarding kernel function to contribute to the activities and functions being focused on in the project. Deviating from the GENERIC configuration means that the trouble of sorting out your problems from those of the GENERIC configuration is too much trouble, and you are on your own. However ... 2) One thing that may not be visible enough is that config(8) can be used to modify kernel parameters without needing to recompile. That gives you a fair amount of customization without deviating from the GENERIC configuration. It is possible to make modifications to the currently running kernel as well as to save these changes in the form of a new kernel binary so that the changes stay even after system restarts. See the section kernel modification in config(8) for more info: http://www.openbsd.org/cgi-bin/man.cgi?query=config Regards, -Lars
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
On Sat, Mar 29, 2008 at 11:00:01AM +0200, Lars Nood??n wrote: ... using the GENERIC kernel ... 2) One thing that may not be visible enough is that config(8) can be used to modify kernel parameters without needing to recompile. That gives you a fair amount of customization without deviating from the GENERIC configuration. It is possible to make modifications to the currently running kernel as well as to save these changes in the form of a new kernel binary so that the changes stay even after system restarts. One thing I'm not clear on: if the only issue is kernel size based on having an old box with low memory, where every MB counts, does deactivating unnecessary drivers with config actually result in a smaller kernel or just a kernel with deactivated drivers? Shrinking the kernel would be the only reason I would have of touching the kernel as I'm not into trying out experimental features. It would be too bad if config doesn't do this. Doug.
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
On Sat, Mar 29, 2008 at 12:58:40PM -0400, Douglas A. Tutty wrote: On Sat, Mar 29, 2008 at 11:00:01AM +0200, Lars Nood??n wrote: ... using the GENERIC kernel ... 2) One thing that may not be visible enough is that config(8) can be used to modify kernel parameters without needing to recompile. That gives you a fair amount of customization without deviating from the GENERIC configuration. It is possible to make modifications to the currently running kernel as well as to save these changes in the form of a new kernel binary so that the changes stay even after system restarts. One thing I'm not clear on: if the only issue is kernel size based on having an old box with low memory, where every MB counts, does deactivating unnecessary drivers with config actually result in a smaller kernel or just a kernel with deactivated drivers? Shrinking the kernel would be the only reason I would have of touching the kernel as I'm not into trying out experimental features. It would be too bad if config doesn't do this. if your machine is low enough on ram that you would even consider recompiling a kernel, just to save ram, it's time to retire the machine. -- [EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
Jacob Meuser wrote: if your machine is low enough on ram that you would even consider recompiling a kernel, just to save ram, it's time to retire the machine. That's for him to decide, not you. It's his machine, and it might be a fairly good one at that, despite being small or old. If you do not know the answer to the question, it is acceptable to be quiet. My machines have more than enough RAM, but what he brings up is an interesting question: does deactivating unnecessary drivers with config actually result in a smaller kernel or just a kernel with deactivated drivers? I'll have to schedule time to try two kernels, one with more deactivated, and compare their resource usage. The deactivation via config(8) definitely speeds up the boot process significantly on the slow units. Regards, -Lars
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
On Sat, Mar 29, 2008 at 09:52:48PM +0200, Lars Nood?n wrote: Jacob Meuser wrote: if your machine is low enough on ram that you would even consider recompiling a kernel, just to save ram, it's time to retire the machine. That's for him to decide, not you. well no fucking shit, Lars. it was a suggestion. -- [EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
On Sat, Mar 29, 2008 at 08:54:05PM +, Jacob Meuser wrote: well no fucking shit, Lars. Now that's something I'd rather not do... :) it was a suggestion.
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
Douglas A. Tutty wrote: ... One thing I'm not clear on: if the only issue is kernel size based on having an old box with low memory, where every MB counts, does deactivating unnecessary drivers with config actually result in a smaller kernel or just a kernel with deactivated drivers? Shrinking the kernel would be the only reason I would have of touching the kernel as I'm not into trying out experimental features. It would be too bad if config doesn't do this. config strictly deactivates the drivers, it doesn't reduce memory consumption or disk footprint. WELL...there MIGHT be a small savings in data structures not allocated for drivers, but that would most likely only be the case if you had such a device in the machine, but deactivated the driver. (i.e., em(4) (the driver) might allocate a RAM buffer for each em(4) card in the machine, but only for the cards in the machine...disable the driver, you don't allocate the buffers, but you can't use the card). Since OpenBSD uses a monolithic kernel, it is outside the ability of config to physically remove the deactivated drivers. That would be a funky kind of relinking, or a bunch of loadable modules, ala Windows or Linux, which is why Windows and Linux needs so much less RAM than OpenBSD. Oh..wait... ;) Removing drivers for reduced memory is really a for advanced users only task, and you VERY QUICKLY run into diminishing returns. One problem is you almost certainly need another computer -- if you have 16M RAM, you want to whittle down the kernel a lot...but $DEITY help you if you need to build that new kernel on that machine, since just sitting at the shell prompt will have you into swap. HOWEVER, by the time you get to 32M, I doubt you will appreciate the time and effort required to build and reboot off a new kernel (even if compiled on another machine). You just won't be adding much functionality to the machine -- there won't be something major you will suddenly be able to do that you couldn't do before. Nick.
