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

Brent D. Norris <[EMAIL PROTECTED]>: > didn't Eric say that this has stalled though? Is that not the case? Nope. Greg is still working. He got the first version of the theorem prover working recently. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond A wise and frugal governme

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

> #2 is fixed by rewriting tools in C didn't Eric say that this has stalled though? Is that not the case? Brent Norris Executive Advisor -- WKU-Linux System Administrator -- WKU-Center for Biodiversity Best Mechanical ___ k

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

Tom Rini <[EMAIL PROTECTED]>: > python1.5.x is compatiable w/ python2 EXCEPT in the cases where the script > uses undocumented things which did work in python1.5.x. That's true of the core language. The reason I moved to 2.0 was that there are library changes in 2.0 that enabled me to to cut CML

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

On Mon, May 21, 2001 at 11:58:34AM +0200, Jes Sorensen wrote: > > "Jakob" == Jakob ?stergaard <[EMAIL PROTECTED]> writes: > > Jakob> On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote: > >> I think this is a very important point, and one I agree with. I > >> tend to let my distri

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

On 21 May 2001 02:11:39 -0400, Mike A. Harris wrote: > On 20 May 2001, Robert M. Love wrote: >>(on another note, about the coexist issue: am i going to have a python >>and python2 binary? so now the config tool will find which to use, ala >>the kgcc mess? great) > > For the record, the kgcc "mess"

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

> "Jakob" == Jakob Østergaard <[EMAIL PROTECTED]> writes: Jakob> On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote: >> I think this is a very important point, and one I agree with. I >> tend to let my distribution handle stuff like python. now, I use >> RedHat's on-going devel,

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

On 20 May 2001, Robert M. Love wrote: >I think this is a very important point, and one I agree with. I tend to >let my distribution handle stuff like python. now, I use RedHat's >on-going devel, RawHide. it is not using python2. in fact, since >switching to python2 may break old stuff, I don't

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

On Mon, 21 May 2001, Jakob Østergaard wrote: > On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote: > > > > im not installing python2 from source just so i can run some new config > > utility. > > python2 will be in rawhide when 2.5 development requires it, if I'm not much > mistaken.

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

On 21 May 2001, Jes Sorensen wrote: > John> Au contraire. It is very reasonable to have both python and > John> python2 installed. Having two different gcc versions installed > John> is a big pain in the arse. > > It's not unreasonable to have both installed, it's unreasonable to > require it

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

On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote: > On 21 May 2001 02:29:17 +0200, Jes Sorensen wrote: > > John> Au contraire. It is very reasonable to have both python and > > John> python2 installed. Having two different gcc versions installed > > John> is a big pain in the arse.

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

On 21 May 2001 02:29:17 +0200, Jes Sorensen wrote: > John> Au contraire. It is very reasonable to have both python and > John> python2 installed. Having two different gcc versions installed > John> is a big pain in the arse. > > It's not unreasonable to have both installed, it's unreasonable to

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

> "John" == John Cowan <[EMAIL PROTECTED]> writes: John> Jes Sorensen wrote: >> Telling them to install an updated gcc for kernel compilation is a >> necessary evil, which can easily be done without disturbing the >> rest of the system. Updating the system's python installation is >> not a re

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

On Fri, May 18, 2001 at 12:34:13PM -0400, Eric S. Raymond wrote: > Even supposing somebody were loony enough to do that, how would preserving > an old interface in amber do anything to explore new UI possibilities? I don't know about the rest of the world, but I _much_ prefer the old menuconfig t

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

Greg Banks <[EMAIL PROTECTED]>: > > In any case, Greg Banks is tracking the > > Python implementation in C (though I don't think he has the theorem > > prover working yet). > > Actually I do, I've just been very quiet about it. > http://www.alphalink.com.au/~gnb/gcml2/chan

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

Eric S. Raymond wrote: > > Greg, scanning your Changelog suggests that you may be unaware that > the `helpfile' declaration is gone from the language. It was a kluge, > now replaced by inline help text sections attached to symbol > declarations (which I know you've implemented). You're right,

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

Eric S. Raymond wrote: > > Michael Elizabeth Chastain <[EMAIL PROTECTED]>: > > I'm comfortable with Python as an implementation language. The speed > > problems seem to be under control. > > Linus is comfortable with it too. That argument seems to be over for > everyone but Jes Sorensen. In a

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

Keith Owens <[EMAIL PROTECTED]>: > Please, please never loose sight of the requirement for kbuild to work > on non-Linux platforms. People cross compile kernels from Solaris, > HP/UX, Cygwin, etc. Python 2.0 runs quite nicely under the Macintosh OS, other Unixes and Cygwin. You could even cross-

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

On Fri, 18 May 2001 14:41:22 -0400, "Eric S. Raymond" <[EMAIL PROTECTED]> wrote: >Michael Elizabeth Chastain <[EMAIL PROTECTED]>: >> It would be nice if either (a) the tools ran with Python 1.5.2 or (b) >> some more time elapses and lots more people have Python 2.0 installed. > >I think we'll get

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

> On 05/18/2001 at 02:44:07 PM [EMAIL PROTECTED] wrote: > >But the real question is whether the old tools have enough value to be > >worth the effort. What problem are you trying to solve here? > > How about: > 1. Some of us are perfectly satisfied with the existing tools and don't want >

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

> But the real question is whether the old tools have enough value to be > worth the effort. What problem are you trying to solve here? Im just playing with ideas and writing a CML1 parser for amusement while I ponder single pass computation of the entire dependancy graph from a CML1 rule base 8

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

On 05/18/2001 at 02:44:07 PM [EMAIL PROTECTED] wrote: >But the real question is whether the old tools have enough value to be >worth the effort. What problem are you trying to solve here? How about: 1. Some of us are perfectly satisfied with the existing tools and don't want them t

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

Alan Cox <[EMAIL PROTECTED]>: > Being able to turn CML2 into CML1 might be the more useful exercise. That's...not a completely crazy idea. Hmmm... It might be possible to take a CML2 rulebase and generate a sort of stupid jackleg CML1 translation of it. The resulting config.in would be huge an

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

Michael Elizabeth Chastain <[EMAIL PROTECTED]>: > Ah, that is where we have different views. I think CML2 would be better > off if you shelved "improving the rulebase" and focussed on "integrating > into the kernel". It's a drop-in install now. Is there something else specific you think I could

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

> For CML1 and CML2 to handle the same language, we would either have > to live with the CML1 language's limitations or retrofit the old tools > to speak CML2 language. The chance of the latter happening is, I think > we can agree, effectively zero. Being able to turn CML2 into CML1 might be the

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

On Fri, 18 May 2001, Eric S. Raymond wrote: > Tom Rini <[EMAIL PROTECTED]>: > > > > SCSI emulation over IDE, CONFIG_BLK_DEV_IDESCSI. You have the SCSI mid > > > > layer code but no SCSI hardware drivers. It is a realistic case for an > > > > embedded CD-RW appliance. > > > > > > Or alternative

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

> "Keith" == Keith Owens <[EMAIL PROTECTED]> writes: Keith> cc trimmed back to mailing lists only. On Fri, 18 May 2001 Keith> 10:53:53 -0400, "Eric S. Raymond" <[EMAIL PROTECTED]> wrote: >> (a) Back off the capability approach. That is, accept that people >> doing configuration are going to

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

Eric Raymond writes: > That's exactly the approach I've taken until very recently. But the > compiler and configurator codebase is stable now. It seemed to me > time to think about improving the rulebase. Ah, that is where we have different views. I think CML2 would be better off if you shelve

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

Michael Elizabeth Chastain <[EMAIL PROTECTED]>: > My two cents: > > I'm in favor of a new description language. > > I'm in favor of new tools for processing it. If you, wearing your CML1 maintainer hat, hadn't made these things clear a year ago ago, CML2 wouldn't exist today. > I'm comfortab

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

Alan Cox <[EMAIL PROTECTED]>: > Do you really believe anyone would be dumb enough to delete them out of spite > or to further your political machinations if they could both handle the same > configuration language. That's a big "if" which I don't think is ever going to happen. The CML1 and CML2

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

My two cents: I'm in favor of a new description language. I'm in favor of new tools for processing it. I'm comfortable with Python as an implementation language. The speed problems seem to be under control. It would be nice if either (a) the tools ran with Python 1.5.2 or (b) some more time e

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

Hi Alan, > CML1 has had no official maintainer for about 4 years. People contribute bits > and it works. So as it stands there would be no reason to remove it. Actually, I actively maintained all three config tools for several months just before the 2.2 release (January 1999). Then I went back

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

> That's ok as long as she doesn't add backstreet boys songtexts as long as your > signature to her mails. I wouldn't worry. She'd be swimming to Cuba in search of asylum from the MPAA if she did > Your point is basically: > Lets rewrite the kernel in VBA to make every word user > ca

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

On Fri, May 18, 2001 at 01:22:35PM -0400, Eric S. Raymond wrote: > Michael Meissner <[EMAIL PROTECTED]>: > > On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote: > > > Aunt Tillie shouldn't try to manually configure a kernel. > > > > Ummm, maybe Aunt Tillie wants to learn how to con

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

Alan Cox <[EMAIL PROTECTED]>: > What I am trying to say is that if you can infer probable configuration > categories that are relevant then instead of automatically filling the other > areas in and blocking changing them without using vi you can put the other > options as a submenu. That guides th

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

> Do you really believe that anyone is going to maintain the CML1 tools > for as long as a nanosecond after they get dropped out of the kernel tree? Do you really believe anyone would be dumb enough to delete them out of spite or to further your political machinations if they could both handle th

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

Michael Meissner <[EMAIL PROTECTED]>: > On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote: > > Aunt Tillie shouldn't try to manually configure a kernel. > > Ummm, maybe Aunt Tillie wants to learn how to configure a kernel After > all, all of us at one point in time were newbi

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

On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote: > Aunt Tillie shouldn't try to manually configure a kernel. Ummm, maybe Aunt Tillie wants to learn how to configure a kernel After all, all of us at one point in time were newbies in terms of configuring kernels, etc. -- Mi

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

On Fri, May 18, 2001 at 12:34:13PM -0400, Eric S. Raymond wrote: > Alan, it sounds very much like you just said something stupid. This > seems sufficiently unlikely that I am shaking my head in disbelief and > fingernailing wax out of both ears (and if you think doing both those > things at once

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

On Friday 18 May 2001 09:19, Jes Sorensen wrote: > Replacing the code does not require changing the style of the config > files. Thats a major problem with CML2, you introduce a new 'let me do > everything for you' tool that relies on a programming language that is > not being shipped by any major

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

On Fri, May 18, 2001 at 12:04:34PM -0400, Eric S. Raymond wrote: > Alan Cox <[EMAIL PROTECTED]>: > > > I don't want to do (a); it conflicts with my design objective of > > > simplifying configuration enough that Aunt Tillie can do it. I won't > > > do that unless I see a strong consensus that it

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

Alan Cox <[EMAIL PROTECTED]>: > > I don't want to do (a); it conflicts with my design objective of > > simplifying configuration enough that Aunt Tillie can do it. I won't > > do that unless I see a strong consensus that it's the only Right Thing. > > Its a good way of getting the defaults righ

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

> I think you're confusing a couple of different issues here, Alan. Even > supposing CML2 could parse CML1 rulesets, the design question about how > configuration *should* work (that is, what kind of user experience we > want to create and who we optimize ruleset design for) wouldn't go away.

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

On Fri, 18 May 2001, Eric S. Raymond wrote: > That being the case, we do face a question of design > philosophy, expressed as a policy question about how to design > rulesets. Actually two questions: > > 1. When we have a platform symbol for a reference design like MVME147, do >we stick to i

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

Christoph Hellwig wrote: > On Fri, May 18, 2001 at 11:51:28AM -0400, John Cowan wrote: > >>Jes Sorensen wrote: >> >> >>>Telling them to install an updated gcc for kernel compilation >>>is a necessary evil, which can easily be done without disturbing the >>>rest of the system. Updating the system

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

On Fri, May 18, 2001 at 11:51:28AM -0400, John Cowan wrote: > Jes Sorensen wrote: > > > Telling them to install an updated gcc for kernel compilation > > is a necessary evil, which can easily be done without disturbing the > > rest of the system. Updating the system's python installation is not a

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

Alan Cox <[EMAIL PROTECTED]>: > > In general this is the best option, if you create a non-standard > > configuration for machine foo then it is your problem, not everybody > > else's. > > Which makes CML2 inferior to CML1 again. Now if it could parse CML1 rulesets > this whole discussion wouldn't

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

> OK, Jes, you've just demonstrated that you're blind to facts and can't > be reasoned with. I'll continue listening to everybody else as I've > been doing, but I'll specifically ignore *you* until you lose the > obstreperous attitude. >From here it has me thinking of pots kettles and a rather

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

Jes Sorensen wrote: > Telling them to install an updated gcc for kernel compilation > is a necessary evil, which can easily be done without disturbing the > rest of the system. Updating the system's python installation is not a > reasonable request. Au contraire. It is very reasonable to have

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

> > (c) Decide not to support this case and document the fact in the > > rulesfile. If you're going put gunge on the VME bus that replaces > > the SBC's on-board facilities, you can hand-hack your own configs. > > In general this is the best option, if you create a non-standard > c

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

> 1. When we have a platform symbol for a reference design like MVME147, do >we stick to its spec sheet or consider it representative of all derivatives >(which may have other facilities)? At most it bounds the busses directly available. I've yet to see VME cardbus adapters but its quite

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

if you punt in case C you should then have a mode where all dependancies are ignored and all options are presented to the person ding the config. This is FAR better then forcing them to hand-hack the config file. possibly split the rules file into two parts. part 1. absolute requirements (i.e. i

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

> "Eric" == Eric S Raymond <[EMAIL PROTECTED]> writes: Eric> Jes Sorensen <[EMAIL PROTECTED]>: >> For a start, so far there has been no reason whatsoever to change >> the format of definitions. Eric> The judgment of the kbuild team is unanimous that you are Eric> mistaken on this. That's t

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

Alan Cox <[EMAIL PROTECTED]>: > I was under the impression the MVME had VME bus. So you can hang IDE off it > and other gunge. Its also a reference design so you may find MVME147 like > boards.. Urk. Alan is right, I misinterpreted the original question. There is no on-board support for IDE or

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

> > Both of these 'problems' assume that you can have IDE or PCMCIA on these > > particular boxes. Does anyone know if that's actually true? > > The answer is: no, you can't. > > I found a feature list for the MVME147 on the web at >

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

Tom Rini <[EMAIL PROTECTED]>: > > > SCSI emulation over IDE, CONFIG_BLK_DEV_IDESCSI. You have the SCSI mid > > > layer code but no SCSI hardware drivers. It is a realistic case for an > > > embedded CD-RW appliance. > > > > Or alternatively, you want to enable SCSI code, with no hardware driver

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

On Thu, May 17, 2001 at 05:35:49AM -0400, Michael Meissner wrote: > On Thu, May 17, 2001 at 05:47:41PM +1000, Keith Owens wrote: > > On Thu, 17 May 2001 03:26:36 -0400, > > "Eric S. Raymond" <[EMAIL PROTECTED]> wrote: > > >Pavel Machek <[EMAIL PROTECTED]>: > > >> And If I want scsi-on-atapi emula

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

On Thu, May 17, 2001 at 05:47:41PM +1000, Keith Owens wrote: > On Thu, 17 May 2001 03:26:36 -0400, > "Eric S. Raymond" <[EMAIL PROTECTED]> wrote: > >Pavel Machek <[EMAIL PROTECTED]>: > >> And If I want scsi-on-atapi emulation but not vme147_scsi? > > > >Help me understand this case, please. What

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

Pavel Machek <[EMAIL PROTECTED]>: > And If I want scsi-on-atapi emulation but not vme147_scsi? Help me understand this case, please. What is scsi-on-atapi? Is SCSI on when you enable it? And is it a realistic case for an SBC? The CML2 constraint language is very flexible. I can make it do the

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

Hi! > > Not all cards have all features, not all users wants to enable all > > features. > > Yes, I understand that. You're not reading the derivations correctly. > Let's take an example: > > derive MVME147_SCSI from MVME147 & SCSI > > This doesn't turn on MVME147_SCSI on every MVME147 board.

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

Jes Sorensen <[EMAIL PROTECTED]>: > If Ray wants to fix things, it's just fine with me. I have corrected the Mac dependencies as Ray directed. > Eric> Does this mean you'll take over maintaining the CML2 rules files > Eric> for the m68k port, so I don't have to? That would be wonderful. > >

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

> "Eric" == Eric S Raymond <[EMAIL PROTECTED]> writes: Eric> Jes Sorensen <[EMAIL PROTECTED]>: Eric> # These were separate questions in CML1 derive MAC_SCC from MAC Eric> & SERIAL derive MAC_SCSI from MAC & SCSI derive SUN3_SCSI from Eric> (SUN3 | SUN3X) & SCSI >> As Alan already pointed out

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

Jes Sorensen <[EMAIL PROTECTED]>: > Not all cards have all features, not all users wants to enable all > features. Yes, I understand that. You're not reading the derivations correctly. Let's take an example: derive MVME147_SCSI from MVME147 & SCSI This doesn't turn on MVME147_SCSI on every MVM

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

> "Eric" == Eric S Raymond <[EMAIL PROTECTED]> writes: Eric> I've said before on these lists that one of the purposes of Eric> CML2's single-apex tree design is to move the configuration Eric> dialog away from low-level platform- specific questions towards Eric> higher-level questions about p

[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 ans

[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 t

[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

[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 > t

[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

[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 y

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

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 somethin

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

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

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

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 imp

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

Tom Rini <[EMAIL PROTECTED]>: > On Sun, May 06, 2001 at 01:58:49PM +0100, Alan Cox wrote: > > > # These were separate questions in CML1 > > > derive MAC_SCC from MAC & SERIAL > > > derive MAC_SCSI from MAC & SCSI > > > derive SUN3_SCSI from (SUN3 | SUN3X) & SCSI > > > > Not all Mac's use the SCC

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

On Sun, May 06, 2001 at 01:58:49PM +0100, Alan Cox wrote: > > # These were separate questions in CML1 > > derive MAC_SCC from MAC & SERIAL > > derive MAC_SCSI from MAC & SCSI > > derive SUN3_SCSI from (SUN3 | SUN3X) & SCSI > > Not all Mac's use the SCC if they have serial > Not all Mac's use the

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

> # These were separate questions in CML1 > derive MAC_SCC from MAC & SERIAL > derive MAC_SCSI from MAC & SCSI > derive SUN3_SCSI from (SUN3 | SUN3X) & SCSI Not all Mac's use the SCC if they have serial Not all Mac's use the same SCSI controller Alan ___