[kbuild-devel] Re: CML2 design philosophy heads-up

2001-05-08 Thread David Weinehall

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//   Full colour fire   /

___
kbuild-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/kbuild-devel



[kbuild-devel] Re: CML2 design philosophy heads-up

2001-05-08 Thread Eric S. Raymond

David Weinehall [EMAIL PROTECTED]:
  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.

That's OK.  Neither of these constraints says PARPORT must be compiled in.
Look at the conditionals carefully.
-- 
a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a

...The Bill of Rights is a literal and absolute document. The First
Amendment doesn't say you have a right to speak out unless the
government has a 'compelling interest' in censoring the Internet. The
Second Amendment doesn't say you have the right to keep and bear arms
until some madman plants a bomb. The Fourth Amendment doesn't say you
have the right to be secure from search and seizure unless some FBI
agent thinks you fit the profile of a terrorist. The government has no
right to interfere with any of these freedoms under any circumstances.
-- Harry Browne, 1996 USA presidential candidate, Libertarian Party

___
kbuild-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/kbuild-devel



[kbuild-devel] Re: CML2 design philosophy heads-up

2001-05-08 Thread Eric S. Raymond

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.
-- 
a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a

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

2001-05-08 Thread Eric S. Raymond

Jamie Lokier [EMAIL PROTECTED]:
 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.

If you're integrating drivers that aren't in the kernel tree, you can and
should patch the CML2 rulebase to compensate.  So your patch for
the modified driver should comment out the PARPORT_PC==PARPORT 
requirement.  Problem solved.

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.
-- 
a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a

The abortion rights and gun control debates are twin aspects of a deeper
question --- does an individual ever have the right to make decisions
that are literally life-or-death?  And if not the individual, who does?

___
kbuild-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/kbuild-devel



[kbuild-devel] Re: CML2 design philosophy heads-up

2001-05-08 Thread Rogier Wolff

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

2001-05-08 Thread Tom Rini

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