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

In article <[EMAIL PROTECTED]> you wrote: > On Mon, May 21, 2001 at 02:29:17AM +0200, Jes Sorensen wrote: >> distributions). 18 months is more realistic for it to be deployed >> widely enough. > People who are going to be savvy enough to install a development 2.5.* > kernel that is defining a new

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

On Sun, May 20, 2001 at 11:33:20PM -0700, Ben Ford wrote: > Not only that, but Alan said that somebody is rewriting it in C. I'll believe it when I see it. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work

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

> On Sun, May 20, 2001 at 11:33:20PM -0700, Ben Ford wrote: > > Not only that, but Alan said that somebody is rewriting it in C. > I'll believe it when I see it. and if not then obviously nobody hates the python one enough ;) - To unsubscribe from this list: send the line "unsubscribe linux-kern

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 - To unsubscribe from this list: send the line "un

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 Monday 21 May 2001 10:01, Tom Rini wrote: > On Mon, May 21, 2001 at 09:58:04AM -0600, Steven Cole wrote: > > On Monday 21 May 2001 09:36, Tom Rini wrote: > > > Which brings up another point, RedHat (7.1?) and Debian/woody both have > > > the option of having python2 around. Anyone know about m

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

On 21 May 2001, Wichert Akkerman wrote: > In article <[EMAIL PROTECTED]>, > Mike A. Harris <[EMAIL PROTECTED]> wrote: > >For the record, the kgcc "mess" you speak of was used by > >Conectiva, and I believe also by debian > > Debian never had that mess. I think that Mike refers to gcc272 being

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

> Mike A. Harris <[EMAIL PROTECTED]> wrote: > >For the record, the kgcc "mess" you speak of was used by > >Conectiva, and I believe also by debian > Debian never had that mess. Debians variant was gcc272 not kgcc. The 2.2.19 makefile knows about both of them - To unsubscribe from this list: send

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

In article <[EMAIL PROTECTED]>, Mike A. Harris <[EMAIL PROTECTED]> wrote: >For the record, the kgcc "mess" you speak of was used by >Conectiva, and I believe also by debian Debian never had that mess. Wichert. -- _ / Noth

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

> i mean how in 2.2 the Makefile must search out for gcc, kgcc, gcc-2.95, > gcc-2.91 etc. what is the cml2 parser going to do? search for my python2 This isnt a CML2 related problem. Problem 1: People who don't like the CML2 description Problem 2: People who don't like python

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

> "Ben" == Ben Ford <[EMAIL PROTECTED]> writes: Ben> Mike Castle wrote: >> People who are going to be savvy enough to install a development >> 2.5.* kernel that is defining a new configuration utility are going >> to be savvy enough to install python. >> Ben> Not only that, but Alan said th

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

Mike Castle wrote: >On Mon, May 21, 2001 at 02:29:17AM +0200, Jes Sorensen wrote: > >>distributions). 18 months is more realistic for it to be deployed >>widely enough. >> > >People who are going to be savvy enough to install a development 2.5.* >kernel that is defining a new configuration utilit

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

On Mon, May 21, 2001 at 02:29:17AM +0200, Jes Sorensen wrote: > distributions). 18 months is more realistic for it to be deployed > widely enough. People who are going to be savvy enough to install a development 2.5.* kernel that is defining a new configuration utility are going to be savvy enoug

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: CML2 design philosophy heads-up

[EMAIL PROTECTED] said: > There are no `advisory' dependencies in CML2. They're all absolute. > What you call an `advisory' dependency would be simulated by having a > policy symbol for Aunt Tillie mode and writing constraints like this: > require AUNT_TILLIE implies FOO >= BAR > This is exact

Re: CML2 design philosophy heads-up

David Woodhouse <[EMAIL PROTECTED]>: > On one hand you have dependencies which are present to make life easier for > Aunt Tillie, by refraining from confusing her with strange questions to > which the answer is _probably_ 'no'. Like the question of whether she has > an IDE controller on her MVM

Re: CML2 design philosophy heads-up

[EMAIL PROTECTED] said: > I don't understand this request. I have no concept of `advisory' > dependencies. What are you talking about? Is my documentation > horribly unclear? By 'dependency' I refer to the case where the value of one symbol is derived entirely from, or the range of possible

Re: CML2 design philosophy heads-up

On Sun, 20 May 2001 11:18:56 -0400, "Eric S. Raymond" <[EMAIL PROTECTED]> wrote: >David Woodhouse <[EMAIL PROTECTED]>: >> The dependencies in CML1 are (supposed to >> be) absolute - the 'advisory' dependencies you're adding are arguably a >> useful feature, but please

Re: CML2 design philosophy heads-up

David Woodhouse <[EMAIL PROTECTED]>: > The dependencies in CML1 are (supposed to > be) absolute - the 'advisory' dependencies you're adding are arguably a > useful feature, but please don't make it possible to confuse the two, and > please do make sure it's possible to

Re: CML2 design philosophy heads-up

[EMAIL PROTECTED] said: > I'll take that as a vote for (b), to handle even perverse > configurations even if it means adding a lot of complexity to the > ruleset. As long as the ruleset is sufficient to represent the desired parts of the original behaviour of CML1, that should be fine. Which

Re: CML2 design philosophy heads-up

> No, my point was, if I don't have SCSI or RAID on this box, I don't want > them to be built into the kernel! They arent built into the kernel. I still think you have your facts confused - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMA

Re: CML2 design philosophy heads-up

Alan Cox wrote: >>Second, how many kernels does Redhat ship in order to have one for >>386/486/586/k6/Athlon . . . . >>Quite a pain in the ass. And look at how much shit has to be built in >>in order to get a kernel that works for everybody! People bitch at >>Microsoft for doing it, then tur

Re: CML2 design philosophy heads-up

> Second, how many kernels does Redhat ship in order to have one for > 386/486/586/k6/Athlon . . . . > Quite a pain in the ass. And look at how much shit has to be built in > in order to get a kernel that works for everybody! People bitch at > Microsoft for doing it, then turn around and do t

Re: CML2 design philosophy heads-up

In article <[EMAIL PROTECTED]> you wrote: > Second, how many kernels does Redhat ship in order to have one for > 386/486/586/k6/Athlon . . . . We build a lot of them :) > Quite a pain in the ass. And look at how much shit has to be built in > in order to get a kernel that works for everybody!

Re: CML2 design philosophy heads-up

Pete Zaitcev wrote: >>[about Aunt Tullie] >>Because, for example, a kernel compile can be a part of the standard >>install now, and you will end up with a kernel built specifically for >>your machine that doesn't print 50 initialization failed messages on boot. >>[...] >>And you can also now ru

Re: CML2 design philosophy heads-up

>[about Aunt Tullie] > Because, for example, a kernel compile can be a part of the standard > install now, and you will end up with a kernel built specifically for > your machine that doesn't print 50 initialization failed messages on boot. >[...] > And you can also now run a kernel built for yo

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

Arjan van de Ven wrote: >"Eric S. Raymond" wrote: > >> >>an old interface in amber do anything to explore new UI possibilities? >> > >kernel != GUI > UI != GUI -- "One trend that bothers me is the glorification of stupidity, that the media is reassuring people it's alright not to know anythi

Re: CML2 design philosophy heads-up

Charles Cazabon wrote: >Eric S. Raymond <[EMAIL PROTECTED]> wrote: > >>Arjan van de Ven <[EMAIL PROTECTED]>: >> >>>Aunt Tillie doesn't even know what a kernel is, nor does she want >>>to. I think it's fair to assume that people who configure and >>>compile their own kernel (as opposed to using th

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

On 05/18/2001 at 03:56:50 PM Mike Castle <[EMAIL PROTECTED]> wrote: >On Fri, May 18, 2001 at 03:04:43PM -0500, [EMAIL PROTECTED] wrote: >> 1. Some of us are perfectly satisfied with the existing tools and don't want >> them to be yanked out from under us. > >Then stay with 2.4.x > Since

Re: CML2 design philosophy heads-up

> > As for the language CML2 is written in, surely C would work just as well as > > Python if the config-ruleset file is in a known format. GCC is required > > for the kernel to build, I don't see why anything else should be required > > simply to configure it. > > Menuconfig is fairly popular,

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

On Fri, May 18, 2001 at 03:04:43PM -0500, [EMAIL PROTECTED] wrote: > 1. Some of us are perfectly satisfied with the existing tools and don't want > them to be yanked out from under us. Then stay with 2.4.x > 2. Some of us have no interest in Python and don't like being forced to deal >

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: CML2 design philosophy heads-up

> Menuconfig is fairly popular, and requires curses.. etc. etc. There isn't > a configurator which doesn't require something more than gcc is there? Configure only requires shell - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTE

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

> 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

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

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

Christoph Hellwig wrote: > That's ok as long as she doesn't add backstreet boys songtexts as long as your > signature to her mails. In fact, they aren't so long once you cut out the repetitions. > On the other hand she should _really_ learn how to do it - like we all did. Hey, nothing sto

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

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: CML2 design philosophy heads-up

On Fri, 18 May 2001, Jonathan Morton wrote: > As for the language CML2 is written in, surely C would work just as well as > Python if the config-ruleset file is in a known format. GCC is required > for the kernel to build, I don't see why anything else should be required > simply to configure it

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: CML2 design philosophy heads-up

> I want to understand what you're driving at here and I don't get it. What's 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

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

In article <[EMAIL PROTECTED]> you wrote: > On Fri, May 18, 2001 at 12:00:59PM -0400, John Cowan wrote: >> Christoph Hellwig wrote: [my voice was snipped here] >> Yes, I should have limited myself to pre-egcs versions. > > Huh? > > It's been possible to have multiple versions of gcc installed fo

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

On Fri, May 18, 2001 at 01:17:07PM -0400, Eric S. Raymond wrote: > It's been an ugly, nasty, horrible job -- *much* nastier, by an order > of magnitude, than designing and writing the CML2 engine. Going the > other direction would be worse. "Like chewing razor blades" is the > simile that leaps

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

Arjan van de Ven <[EMAIL PROTECTED]>: > I hereby volunteer to maintain at least make oldconfig and make config, > and perhaps make menuconfig. That's the easy part; the CML1 config code may be ugly and broken, but at least it's relatively stable. What you'd also have to do is maintain an entire

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

On Fri, May 18, 2001 at 12:00:59PM -0400, John Cowan wrote: > Christoph Hellwig wrote: > Yes, I should have limited myself to pre-egcs versions. Huh? It's been possible to have multiple versions of gcc installed for a very long time. At least since 2.0 came out. Thu Dec 19 15:54:29 1991 K. Ri

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

Arjan van de Ven <[EMAIL PROTECTED]>: > Right now, it's now a dropping back. You seem to take for granted that CML2 > and your python2 frontend to it are 2.5.0 material. I don't right now. Linus is free to change his mind. Perhaps he will. But the last word I heard from him is that CML2 goes in

Re: CML2 design philosophy heads-up

At 04:22 PM 5/13/01 +0200, you wrote: >I've said before on these lists that one of the purposes of >CML2's single-apex tree design is to move the configuration >dialog away from low-level platform- specific questions towards >higher-level questions about policy or intentions. > >Or to put another

Re: CML2 design philosophy heads-up

On Friday 18 May 2001 17:11, Arjan van de Ven wrote: > >(a) Back off the capability approach. That is, accept that > >people doing configuration are going to explicitly and > >exhaustively specify low-level hardware. > > > > > I don't want to do (a); it conflicts with my desi

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

On 05/18/2001 at 11:45:40 AM [EMAIL PROTECTED] wrote: >I hereby volunteer to maintain at least make oldconfig and make config, >and perhaps make menuconfig. THANK YOU THANK YOU THANK YOU!!! I'm quite happy with the current form of oldconfig and menuconfig, and will continue to use them as lon

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

Michael Meissner wrote: > > 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

Re: CML2 design philosophy heads-up

Arjan van de Ven <[EMAIL PROTECTED]>: > In my opinion, no configuration that is actually physically possible > is perverse. Noted. And a very pithy statement of the position. Thanks. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond I do not find in orthodox Christianity one r

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

"Eric S. Raymond" wrote: > > It would. Because people who like the old config would continue to use the > > old tools > > Excuse me? > 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? I hereby volu

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

Alan Cox <[EMAIL PROTECTED]>: > > 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 r

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: CML2 design philosophy heads-up

Jonathan Morton <[EMAIL PROTECTED]>: > Not everyone falls into the "expert user" and "Aunt Tillie" categories. > It's a *very* big grey area. If some semi-computer-literate user (ie. some > friends of mine!) wants to upgrade their kernel so they have access to > newer hardware (such as a cheap US

Re: CML2 design philosophy heads-up

"Eric S. Raymond" wrote: > > Arjan van de Ven <[EMAIL PROTECTED]>: > > Don't get me wrong. I'm NOT opposed to having a config tool everyone and > > their aunt can use. I'm opposed to that tool taking away the options expert > > users have to do what they know is right for them. > > I'll take tha

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: CML2 design philosophy heads-up

Alan Cox wrote: >At most it bounds the busses directly available. I've yet to see VME cardbus >adapters but its quite possible. You didn't try google did you? *grin* http://www.ramix.com/products/busadapters/rm235m.html /Christer -- "Just how much can I get away with and still go to hea

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

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

> 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, 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

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: CML2 design philosophy heads-up

>> Aunt Tillie doesn't even know what a kernel is, nor does she want >> to. I think it's fair to assume that people who configure and >> compile their own kernel (as opposed to using the distribution >> supplied ones) know what they are doing. > >I'd like to break these assumptions. Or at the ver

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

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

Re: CML2 design philosophy heads-up

Arjan van de Ven <[EMAIL PROTECTED]>: > Don't get me wrong. I'm NOT opposed to having a config tool everyone and > their aunt can use. I'm opposed to that tool taking away the options expert > users have to do what they know is right for them. I'll take that as a vote for (b), to handle even perv

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

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

Re: CML2 design philosophy heads-up

David Lang <[EMAIL PROTECTED]> wrote: > > Whether this is desirable or not is debatable. The big question is: why > > on earth would Aunt Tillie _want_ to compile a kernel at all, let alone > > re-configure one? If she's using Linux, she's installing her > > distribution's pre-compiled kernel,

Re: CML2 design philosophy heads-up

On Fri, 18 May 2001, Jes Sorensen wrote: > Oh I don't, on the other hand I see you consistently ignoring the > needs and requirements of the users. So far I haven't heard a single > developer say something positive about CML2, the most positive I have > heard so far has been "whatever", "it's his

Re: CML2 design philosophy heads-up

> Simplifying the configuration interface so that "anyone" can use it seems like > a waste of effort. If there's an interested novice out there who wants to > learn how to configure a kernel, they'll be sufficiently interested to invest > an hour or two in learning how the whole process works. M

Re: CML2 design philosophy heads-up

On Fri, May 18, 2001 at 11:26:25AM -0400, Eric S. Raymond wrote: > I'd like to break these assumptions. Or at the very least see how far > they can be bent. I know this sounds crazy to a lot of hackers, but > I think there's a certain amount of unhelpful elitism and self-puffery > in the "kerne

Re: CML2 design philosophy heads-up

;[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: CML2 design philosophy heads-up > > Eric S. Raymond <[EMAIL PROTECTED]> wrote: > > Arjan van de Ven <[EMAIL PROTECTED]>: > > > Aunt Tillie doesn't even know what a kernel is, nor does she w

Re: CML2 design philosophy heads-up

Eric S. Raymond <[EMAIL PROTECTED]> wrote: > Arjan van de Ven <[EMAIL PROTECTED]>: > > Aunt Tillie doesn't even know what a kernel is, nor does she want > > to. I think it's fair to assume that people who configure and > > compile their own kernel (as opposed to using the distribution > > supplied

Re: CML2 design philosophy heads-up

Arjan van de Ven <[EMAIL PROTECTED]>: > Aunt Tillie doesn't even know what a kernel is, nor does she want > to. I think it's fair to assume that people who configure and > compile their own kernel (as opposed to using the distribution > supplied ones) know what they are doing. I'd like to break t

Re: CML2 design philosophy heads-up

Keith Owens wrote: > > (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 creat

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

Re: CML2 design philosophy heads-up

:53:53 -0400 > From: Eric S. Raymond <[EMAIL PROTECTED]> > To: Alan Cox <[EMAIL PROTECTED]> > Cc: Tom Rini <[EMAIL PROTECTED]>, > Michael Meissner <[EMAIL PROTECTED]>, > Keith Owens <[EMAIL PROTECTED]>, CML2 <[EMAIL PROTECTED]>, >

Re: CML2 design philosophy heads-up

>(a) Back off the capability approach. That is, accept that >people doing configuration are going to explicitly and >exhaustively specify low-level hardware. > I don't want to do (a); it conflicts with my design objective of > simplifying configuration enough that Aunt Ti

Re: CML2 design philosophy heads-up

cc trimmed back to mailing lists only. On Fri, 18 May 2001 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 explicitly and > exhaustively specify low-level hardware

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 >

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

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

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.

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. > >

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

  1   2   >