* T. Valent <tmp...@4ss.de> [2011-12-01 10:19]: > > It certainly sounds interesting. Out of curiosity: what do these > > system do? Are their routers? Rocket launchers? > These machines are used for measuring and controlling. (In German: > Steuerungscomputer). Now come on. I got complaints about "wasting > peoples time". Let's not talk about things that have absolutely nothing > to do with my problem.
"out of curiosity" was pretty clear, no? isn't it kinda natural that people are interested in uncommon use cases of the OS they write / are part of the community? > >> I can provide a dmesg from a virtual machine > > A dmesg from the actual machine would; really, it would. > The dmesg I provided is not from one of the production machines, but > from a VM on which I wasn't yet able to compile a minimal kernel, too. > So if you say the dmesg helps, there you are! still doesn't help a bit for figuring out what you might need on your production system. > > Because if someone simply says "this is impossible", it is only > > natural to ask "why is that impossible?". > Might be a question of culture. For me this doesn't sound "natural". If > I'm being asked a question and given (detailed?) circumstances, I'd try > to answer and take the circumstances as they are. I believe the person > asking me might have reasons to tell me that this and that ain't > possible, otherwise he wouldn't have said it, right? people often incorrectly assume an "impossible" is a given. when it isn't really. and instead of stupid ways to work around the problem you can give them a beter solution. your situation is partially exactly that, see below. > Say you ask a lawyer about what to do after you've stolen a Picasso and > while you tried to sell it somewhere, it caught fire and was burned > down. You tell the lawyer that there's no way you can give it back and > you need an advice. Would you find it "natural" that the lawyer ignores > that you said you cannot give it back and instead keeps on asking > questions about where you burnt it, what you burnt it with, how hot the > fire was, where the ashes are now and what the painting smelled like? the lawyer would care about the "why is it impssible to give back". and your answers to the "why?" aren't as convincing as a "can't give back anytjing but the ashes". > > So the 32MB storage is a CF card? Don't be surprised that > > people ask, because it begs the question (no really, it does): > > why can't you put a bigger CF card in there that would > > just hold GENERIC? No, really: why? Answering this question > > will take a few minutes of our time. > These machines (>100) are not on site here. The flash mem is inside a > box which the people who run the box would have to screw open. so. the decision to employ such a crippled system instead of using bigger flash was a bad one. you can try to work around that or draw the right conclusion - the extra cost for a flash card of a reasonable size, yes even hundreds of cases, can't be cheaper than the (not free) work time it takes you to build your strange images. now with a reasonable flash where you could just use mostly-standard kernels... of course that doesn't help you with your installed base. the question wether it is really a clever idea to invest a lot of time to build a system that fits in 32M (repeatedly, not just once) versus upgrading flash - which, yes, costs money too - is a valid one. > Ever been given a > project and then tried to discuss the project goals because you didn't > find the solution (required lines in the config) within 3 days? when the goals were stupid (and too specific, the real goal was usually another from which the wrong conclusions lead to the "project goals"), yes, repeatedly. a good move. > > You have been told several times already: strip GENERIC down to what > > will fit on your system. Start with things you definitely do not need > > (sound? wifi?), then continue with the rest. If things break, put > > the last thing that you removed back there. It is a way to arrive > > at the smallest possible kernel that works for you. Isn't it? > That's the way I've done it in the past (since OpenBSD 3.5). Because > this is a lot of work to be done each time I'd update to a new OpenBSD > version (which I admit I haven't done with every release), I was > thinking I'd better try to understand what is really required at > minimum. And then do it the other way round: Start with an empty file > and add the entries I found to be required. To achieve this goal, I > asked you folks. you have been given the answer repeatedly: start with GENERIC(.MP) and start stripping. you don't like the answer, but that doesn't make it wrong or bad or anything like that. > What I've learned now from this discussion is: Either there is no way to > do it bottom up, or you folks don't know it either. what do you expect? us explaining you every single line in GENERIC? ridiculous. offload YOUR job to the community. awesome. that rightly fails. and yes, there is very little knowledge about stripping kernels in the community because it is, in almost any case, stupid. heck, I'll waste some of my time to be nice. the lines you want to lok at and possibly remove are either "option" lines. option FOO in teh kernel config leads to FOO defined. thus you check the code for #ifdef / #ifndef / # if etc FOO and know what it does if it isn't obvious for from the name already. foo at bar are drivers. they have manpages. pseudo-device lines also include "drivers" - devices that don't map to a piece fo hardware (real or emulated). they have manpages. there. the rest is your own work that you have to do yourself. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
