[kbuild-devel] Re: CML2 design philosophy heads-up
On Mon, May 07, 2001 at 09:56:18PM -0400, Eric S. Raymond wrote: > Tom Rini <[EMAIL PROTECTED]>: > > Only sort-of. There are some cases where you can get away with > > that. Probably. eg If you ask for PARPORT, on x86 that means yes > > to PARPORT_PC, always (right?) > > Yes. So the right answer there isn't to use a derivation but to say: > > require X86 and PARPORT implies PARPORT_PC > unless X86==n suppress PARPORT_PC > > which forces PARPORT_PC==y and makes the question invisible on X86 > machines, but leaves the question visible on all others. Yes, but there are quite a lot of people who don't want parport/serial/whatever compiled into their kernels at all, eventhough they have an x86. Think low-memory systems or similar. /David _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
Eric S. Raymond wrote: > Tom Rini <[EMAIL PROTECTED]>: > > Only sort-of. There are some cases where you can get away with that. > > Probably. eg If you ask for PARPORT, on x86 that means yes to PARPORT_PC, > > always (right?) > > Yes. So the right answer there isn't to use a derivation but to say: > > require X86 and PARPORT implies PARPORT_PC > unless X86==n suppress PARPORT_PC > > which forces PARPORT_PC==y and makes the question invisible on X86 machines, > but leaves the question visible on all others. Which is unfortunately wrong if you want the parport subsystem on x86 but won't be using the parport_pc driver with it. I.e. you'll be using some other driver which isn't part of the kernel tree. Perhaps a modified version of parport_pc, perhaps something else. The default should be PARPORT_PC==y, but it's actually valid for some applications to _require_ PARPORT_PC==n or PARPORT_PC==m. -- Jamie ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
On Mon, May 07, 2001 at 09:31:40PM -0400, Eric S. Raymond wrote: > Tom Rini <[EMAIL PROTECTED]>: [snip] > Exactly. In fact we can be more specific -- the "Macintoshes" in > question are the old-fashioned NuBus-based 68k toaster boxes, not the > more recent designs with a PCI bus. Relevant stuff in the > Configure.help implies that MAC_SCC and MAC_SCSI enable support for > the on-board hardware built into those puppies. > > > But Alan's point is a good one. There are _lots_ of cases you can't get away > > with things like this, unless you get very fine grained. In fact, it would > > be much eaiser to do this seperately from the kernel. Ie another, > > possibly/probably _not_ inkernel config tool which asks what machine you > > have, picks lots of sane defaults and setups a kernel config for you. This > > is _sort of_ what PPC does right now with the large number of 'default > > configs' (arch/ppc/configs). > > You're really talking about a different issue here, autoconfiguration > rather than static dependencies. Giacomo Catenazzi is working on that. Only sort-of. There are some cases where you can get away with that. Probably. eg If you ask for PARPORT, on x86 that means yes to PARPORT_PC, always (right?) On other arches (someone brought this up before) it could be PC, it could be something else. My point is there are only some cases where you can get away with asking for serial and knowing the driver. I've given this some thought before, and at least on PPC, you can at best segment off some drivers as depending on family X, but family X doesn't mean you have part Y. The other thing to keep in mind is I'm sure there's lots of unintentionally correct bits. In short, please be very careful when you change a symbol from a question to a derive. You're bound to piss off someone :) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
Eric S. Raymond wrote: > More generally, arguments of the form "Non-mainline custom hack X > could invalidate constraint Y, therefore we can't have Y in the > rulebase" are dangerous -- I suspect you could reduce your set of > constraints to nil very quickly that way, and thus badly screw over > the 99% of people who just want to build a more or less stock kernel. Eric, Still being able to use the "tool" is useful! So I want a "don't mess with me" mode where I'd get more control than 99% of the lusers Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
Alan Cox <[EMAIL PROTECTED]>: > There are also a lot of config options that are implied by your setup in > an embedded enviromment but which you dont actually want because you didnt > wire them Well, then, you don't specify the guard capability! If your MV147 isn't wired for serial, then leave SERIAL off. The point of the derivation is exactly to let you do that. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond Sometimes the law defends plunder and participates in it. Sometimes the law places the whole apparatus of judges, police, prisons and gendarmes at the service of the plunderers, and treats the victim -- when he defends himself -- as a criminal. -- Frederic Bastiat, "The Law" ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
> > Not all Mac's use the same SCSI controller > > Yes, but in this case 'MAC' means m68k mac, which this _might_ be valid, but > I never did get Linux up and running on the m68ks I had.. 68K macs use the 53C80 and 53C9x controllers > But Alan's point is a good one. There are _lots_ of cases you can't get away > with things like this, unless you get very fine grained. In fact, it would > be much eaiser to do this seperately from the kernel. Ie another, There are also a lot of config options that are implied by your setup in an embedded enviromment but which you dont actually want because you didnt wire them Second guessing is not ideal. As a 'make the default config nice' trick - great ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
