On Dec 01 09:44:25, T. Valent wrote: > > 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? > > > > (Solving your problem is impossible. Really. > > Don't waste your time asking why.) > > This is the exact kind of answer you have to expect in certain > situations. Why should I question the conclusion of an expert that I > asked? If I knew better, why should I ask an expert? > > 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?
That's a very weak analogy. A better analogy would be - So why don't you give the painting back? - That's impossible. - Why is it impossible? - Because I burned it. Can you spot the difference between this and the following? - So why don't you put a bigger CF card in there? - That's impossible. - Why is that impossible? - Don't ask. > I am an expert for the circumstances of this very defined little problem > I have. I was seeking for help to find an answer to the question "Which > drivers are required for proper system functioning". That's it. No, that's not it. You have said several times that you are NOT looking for an answer that goes "add these three lines and it will work". Isn't that exactly adding the drivers that are required? > I doubt that this is a question that cannot be answered. And I doubt > that answering this question has to do with the hardware or what it is > used for. LOLWUT? The set of pieces required to be in the kernel does not depend on which hardware you run? > > 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. See? If you spent ten seconds putting this into your first email, nobody would question that it is indeed ruled out. > The one reason that should stop all discussion about this: The project > goal is to update existing systems by software only. 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? I'm sure > I can solve this since I have been able to in the past. I am sure you can (no sarcasm here), and that you have. So why don't you do the same you did before? What *did* you do before? Strip GENERIC down to what you absolutely need to have? Did it work? > I was just > seeking for help to maybe find a quicker and more structured way than > "fiddling" around with the config. By definition, you *are* fiddling with kernel config. > > 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. > > 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. I don't think there is a way to arrive to a minimal working kernel from below that would be easier/faster than striping down to a minimal kernel from above. Not if you know the internal dependencies in various parts of the kernel. (I sure don't.) Some of that information probably lives in the set of Makefiles in the src tree.
