Le mar 08/04/2003 à 14:23, Robert P. J. Day a écrit : > in other words, you're building in a *support system* for unselected > features, but without actually picking these features, it's not > doing you much good. that's why i was thinking that a reworking > of that entire config menu might be in order -- why let users > pick what turns out to be a non-functional set of options? It is not really non-functional. If I were a developper, I could build a kernel with IP tables selected and no table, just to test the table I am developping. That's just an example, but I think someone can find some good reason ;) I must admit that, from a strict user poijnt of vue, I can't see any good reason. > it would make far more sense to have a list of menu options > that reflects what a user would want to *do*, and have the > underlying dependencies kept invisible. a more readable menu > like: > > Basic filtering > Connection tracking > NAT > Packet mangling This does not reflect reality. Connection tracking does not depend on basic filtering. It's even completly independent form it. It does not depend on NAT either. > gotcha. if you want masq/NAT, you would have to select > not only Connection tracking, but IPtables support and, > within that, "Full NAT". and that's why i dislike the current > menu layout. it would be more reasonable for someone to say, > "i want NAT", and have the underlying dependencies automatically > satisfied. I see your point. But I do think connection tracking has to appear as a independent choice. But some conntrack dependencies could appear non-selected. As an example, NAT could appear anyway, and if you were to select it, then it would automaticly select connection tracking as well. I don't know if it's possible to do such dependencies into kernel configuration (in fact, I don't think so). My 0.02€ about this is that I personaly prefer a configuration script that reflect reality, than something more "user convenient" that could fool people about the way things work. Netfilter insides, as well as kernel insides, are already complicated enough to me, for I do not need stuff that could make me misunderstand something. Reality is that NAT depends on conntrack. Your point would be to invert this for user's sake, and this is, imho, a baaaaad thing ;) I don't know if any of them are reading this thread, but if we could have some core developper's point of vue about his, would be great. It is a very tough subject to discuss how kernel configuration must be presented. I wouldn't show nerd's behaviours, e.g. dumb users do not compile kernel, but I tend to think that if someone wants to build its own kernel, then it's up to him to (try to ?) understand how it is going and what are the choices he's about to make. Cc netfilter-devel. -- Cédric Blancher <blancher@xxxxxxxxxxxxxxxxxx> IT systems and networks security - Cartel Sécurité Phone : +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99 PGP KeyID:157E98EE FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE
