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

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

[Wayne.Brown]

On 05/18/2001 at 02:44:07 PM esr@thyrsus.com 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 to be yanked out from under us.

2.  Some of us have no interest in Python and don't like being forced to deal
      with installing/upgrading it just for CML2.



Wayne

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

[Alan Cox]

> On 05/18/2001 at 02:44:07 PM esr@thyrsus.com 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 to be yanked out from under us.

> 2.  Some of us have no interest in Python and don't like being forced to deal
>       with installing/upgrading it just for CML2.

Since someone is rewriting CML2 in C that #2 is a non issue. #1 may be a case
of bolting alternative ui's onto the parser 

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

[Mike Castle]

On Fri, May 18, 2001 at 03:04:43PM -0500, Wayne.Brown@altec.com 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
>       with installing/upgrading it just for CML2.


Some don't like installing/upgrading the following just for a kernel:

gcc
binutils
modutils
mount
Not to mention netfilter.
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  dalgoda@ix.netcom.com  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

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

[Wayne.Brown]

On 05/18/2001 at 03:56:50 PM Mike Castle <dalgoda@ix.netcom.com> wrote:

>On Fri, May 18, 2001 at 03:04:43PM -0500, Wayne.Brown@altec.com 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 doing kernel upgrades is my whole reason for using the tools, that's not a
very helpful suggestion.  It's a little like saying, "If you don't like the way
the air smells, just stop breathing."

>> 2.  Some of us have no interest in Python and don't like being forced to deal
>>       with installing/upgrading it just for CML2.
>
>
>Some don't like installing/upgrading the following just for a kernel:
>
>gcc
>binutils
>modutils
>mount
>Not to mention netfilter.

I don't especially like upgrading these things, either, and don't do it unless I
absolutely have to (that's why I'm still on egcs-2.91.66), but the kernel is
important enough to be worth the trouble.  If I have to use CML2 to move into
2.5.x, then I will.  However, upgrading a programming language I don't use, just
so I can replace a perfectly good tool with one I don't want, in order to do a
job that's always been easy to accomplish with the existing tools... well, that
seems a lot like a solution in search of a problem.

Fortunately, Alan's response about someone re-writing CML2 in C offers hope for
at least part of the issue.

Wayne

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

[Wayne.Brown]

On 05/18/2001 at 11:45:40 AM arjanv@redhat.com 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 long as they're
available.

Wayne

Re: CML2 design philosophy heads-up

[Keith Owens]

cc trimmed back to mailing lists only.

On Fri, 18 May 2001 10:53:53 -0400, 
"Eric S. Raymond" <esr@thyrsus.com> wrote:
>   (a) Back off the capability approach.  That is, accept that 
>       people doing configuration are going to explicitly and 
>       exhaustively specify low-level hardware.

No, you loose one of the nicer features of CML2.

>   (b) Add complexity to the ruleset.  Split SCSI into SCSI_MIDLEVEL and 
>       SCSI_DRIVERS capabilities, make sure SCSI_DRIVERS is implied
>       whenever a SCSI card is configured, etc.

As a specific case this needs doing anyway, to handle SCSI emulation
over IDE, irrespective of the board type.  It needs mid layer but no
SCSI driver and can be done on a PC right now.

As a general question, I prefer selecting machine type foo to mean just
that, you get the devices supported by foo.

>   (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
configuration for machine foo then it is your problem, not everybody
else's.

Re: CML2 design philosophy heads-up

[Alan Cox]

> >   (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
> 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 be needed. 

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

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > 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 be needed. 

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.

I'm raising these questions now because CML2's capabilities invite 
thinking about them.  But they're independent of the underlying language.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

To stay young requires the unceasing cultivation of the ability to
unlearn old falsehoods.
	-- Lazarus Long 

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

[Alan Cox]

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

It would. Because people who like the old config would continue to use the 
old tools

Alan

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

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > 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.
> 
> It would. Because people who like the old config would continue to use the 
> old tools

Excuse me?

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 is easy try it sometime :-)).

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?

Even supposing somebody were loony enough to do that, how would preserving
an old interface in amber do anything to explore new UI possibilities?

Perhaps I'm just unusually dense this morning.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Alcohol still kills more people every year than all `illegal' drugs put
together, and Prohibition only made it worse.  Oppose the War On Some Drugs!

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

[Christoph Hellwig]

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 is easy try it sometime :-)).
> 
> 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 _will_ continue to maintain mconfig (after mec stopped even before cml2).

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

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

[Arjan van de Ven]

"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 volunteer to maintain at least make oldconfig and make config, 
and perhaps make menuconfig.

 
> Even supposing somebody were loony enough to do that, how would preserving
> an old interface in amber do anything to explore new UI possibilities?

kernel != GUI

There are plenty of UI kernel configurators out there. Good ones. Bad
ones. 
LOOK AT THEM. FIX THEM if you don't like them. But PLEASE don't even
think
about taking the current, very useful for advanced users, tools away
without
offering something of at least the same capabilities.

 
> Perhaps I'm just unusually dense this morning.

Given the rest of this thread, unusual is not the word that comes to my
mind
(sorry, open door and you asked for it)

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

[Eric S. Raymond]

Arjan van de Ven <arjanv@redhat.com>:
> 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 CML1 ruleset in parallel with the canonical CML2 one.  That's 
the hard part.

I've been keeping the CML2 ruleset synced with CML1 for a year now. 
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 to mind.

(And no, dropping back to CML1 format for the masters wouldn't be an
option; it doesn't have the semantic strength to enable CML2's new
capabilities.)
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Certainly one of the chief guarantees of freedom under any government,
no matter how popular and respected, is the right of the citizens to
keep and bear arms.  [...] the right of the citizens to bear arms is
just one guarantee against arbitrary government and one more safeguard
against a tyranny which now appears remote in America, but which
historically has proved to be always possible.
        -- Hubert H. Humphrey, 1960

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

[Arjan van de Ven]

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

And you hope this will not be razorblades if Linus decides he likes CML2 ?

 
> (And no, dropping back to CML1 format for the masters wouldn't be an
> option; it doesn't have the semantic strength to enable CML2's new
> capabilities.)

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.

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

[Eric S. Raymond]

Arjan van de Ven <arjanv@redhat.com>:
> 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 in the 2.5.1-2.5.2 timeframe.  That's the
assumption I'm operating on.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

An armed society is a polite society.  Manners are good when one 
may have to back up his acts with his life.
        -- Robert A. Heinlein, "Beyond This Horizon", 1942

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

[Ben Ford]

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 anything. That to me is far more 
dangerous than a little pornography on the Internet." 
  - Carl Sagan

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

[Alan Cox]

> 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 the same
configuration language.

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.

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

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> 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 languages are nowhere near semantically equivalent.  I
know them both intimately, and bridging the gap is a much harder
problem than you seem prepared to realize.

They look closer together than they are, because you can superficially
map individual features between them (CML2 derivations look like CML1
defines, for example).  The big difference is subtler, and has to do with
the difference between a control language and a constraint language.  As
a result, there are things you can easily do in CML2 that you can't 
practically speaking do in CML1.

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.

I know you've talked about parsing CML1 into constraints with
backtracking.  Maybe you're smart enough to do that.  I'm not.  I
tried that route early on.  I predict that if you do, you'll
experience a great deal of suffering, acquire a valuable education,
and get no good result.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The common argument that crime is caused by poverty is a kind of
slander on the poor.
	-- H. L. Mencken

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

[Alan Cox]

> 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 more useful exercise.

Alan

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

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> 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
and nasty, and would only work in forward sequence with no side-effect
computation, but you just might be able to get the old tools to parse it.

Again there's a technical problem with derivations.   Probably solvable.

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

This would be the best of all possible worlds, if there were
no religion in it.
	-- John Adams, in a letter to Thomas Jefferson.

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

[Alan Cox]

> 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

[Aaron Lehmann]

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 to CML2's menuconfig. While I haven't spent much time playing
with CML2, I'm familiar with cml1's tools and see no reason why they
need changes, which IMHO (so far) are detrimental.

That's not even to mention python issues, speed, or anything else.

Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> 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 PCMCIA, but you could plug in an IDE
daughterboard with an IDE drive or a PCMCIA slot.  This would be a
pretty damn perverse thing to do, however -- there are newer, less
expensive, faster, and generally better SBCs that have IDE/ATAPI and
PCMCIA built in.  On top of that, VMEbus SBCs aren't normally used for
consumer devices -- their market is basically industrial-control
applications with a side of scientific instrumentation.

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 its spec sheet or consider it representative of all derivatives
   (which may have other facilities)?

I know my answer to this one, which I will implement unless there's
strong consensus otherwise.  I go for explicitness.  If we're going to
support MVME147 derivatives and variants in the ruleset, they get
their own platform symbols.

2. How much extra tsuris should we accept in order to handle
   perverse edge cases like this one?  There are three ways we
   can cope:

   (a) Back off the capability approach.  That is, accept that 
       people doing configuration are going to explicitly and 
       exhaustively specify low-level hardware.

   (b) Add complexity to the ruleset.  Split SCSI into SCSI_MIDLEVEL and 
       SCSI_DRIVERS capabilities, make sure SCSI_DRIVERS is implied
       whenever a SCSI card is configured, etc.

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

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.

The larger question in choosing between (b) and (c) is one of the usual ones
in programming -- that is, generality vs. maintainability.  Is it ever 
acceptable for the configuration system to deliberately punt an edge case
like this one in order to keep from having a combinatorial-complexity
explosion in the ruleset?

I know what my sense of taste and proportion says.  But I'm not going
to impose my vision on everybody.  If you have an opinion, I'd like
to hear it.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Whether the authorities be invaders or merely local tyrants, the
effect of such [gun control] laws is to place the individual at the 
mercy of the state, unable to resist.
        -- Robert Anson Heinlein, 1949

Re: CML2 design philosophy heads-up

[Alan Cox]

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

> 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 right. It may also be an appropriate
way of guiding presentation (eg putting the stuff the ruleset says you wont
have under a subcategory so you would see


		CPU type
		Devices
		blah
		blah
		Other Options
			IDE disk
			Cardbus

Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > 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 right. It may also be an appropriate
> way of guiding presentation (eg putting the stuff the ruleset says you wont
> have under a subcategory so you would see
> 
> 
> 		CPU type
> 		Devices
> 		blah
> 		blah
> 		Other Options
> 			IDE disk
> 			Cardbus

I want to understand what you're driving at here and I don't get it.  What's
the referent of "Its"?  Are you saying you think Aunt Tillie's view of the
world should guide the presentation of options?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Are we at last brought to such a humiliating and debasing degradation,
that we cannot be trusted with arms for our own defence?  Where is the
difference between having our arms in our own possession and under our
own direction, and having them under the management of Congress?  If
our defence be the *real* object of having those arms, in whose hands
can they be trusted with more propriety, or equal safety to us, as in
our own hands?
        -- Patrick Henry, speech of June 9 1788

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

[Christoph Hellwig]

On Fri, May 18, 2001 at 12:04:34PM -0400, Eric S. Raymond wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > > 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 right. It may also be an appropriate
> > way of guiding presentation (eg putting the stuff the ruleset says you wont
> > have under a subcategory so you would see
> > 
> > 
> > 		CPU type
> > 		Devices
> > 		blah
> > 		blah
> > 		Other Options
> > 			IDE disk
> > 			Cardbus
> 
> I want to understand what you're driving at here and I don't get it.  What's
> the referent of "Its"?  Are you saying you think Aunt Tillie's view of the
> world should guide the presentation of options?

Aunt Tillie shouldn't try to manually configure a kernel.

	Christoph

P.S. _please_ shorten your .sig
-- 
Whip me.  Beat me.  Make me maintain AIX.

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

[Michael Meissner]

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.

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

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

[Arjan van de Ven]

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 of configuring

And maybe she uses KDE and clicks kkernelconfigurator for the first
steps.
And if she wants to learn, she even might stumble on the HOWTO..

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

[Eric S. Raymond]

Michael Meissner <meissner@spectacle-pond.org>:
> 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.

And if she doesn't, maybe her teenage daughter Muffy wants to learn.  You know,
the one with the unicorn appliques and the pink scrunchies and the Back Street
Boys posters in her bedroom?

Dammit, if we're serious about empowering people with free software we can't
limit ourselves with the attitude that configuring kernels (or anything
else) is the sacred preserve of a geek elite.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The price of liberty is, always has been, and always will be blood.  The person
who is not willing to die for his liberty has already lost it to the first
scoundrel who is willing to risk dying to violate that person's liberty.  Are
you free? 
	-- Andrew Ford

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

[Christoph Hellwig]

On Fri, May 18, 2001 at 01:22:35PM -0400, Eric S. Raymond wrote:
> Michael Meissner <meissner@spectacle-pond.org>:
> > 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.
> 
> And if she doesn't, maybe her teenage daughter Muffy wants to learn.  You know,
> the one with the unicorn appliques and the pink scrunchies and the Back Street
> Boys posters in her bedroom?

That's ok as long as she doesn't add backstreet boys songtexts as long as your
signature to her mails.

On the other hand she should _really_ learn how to do it - like we all did.

> Dammit, if we're serious about empowering people with free software we can't
> limit ourselves with the attitude that configuring kernels (or anything
> else) is the sacred preserve of a geek elite.

I see _no_ reason to give up my control for people with an attitude that
configuring kernels will not need knowledge of what one is doing.

Your point is basically:

	Lets rewrite the kernel in VBA to make every word user
	capable of driver hacking.

That doesn't work.

	Christoph
--
Auch der Dumme hat manchmal einen gescheiten Gedanken.
Er merkt es nur nicht.  -- Danny Kaye

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

[Alan Cox]

> 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
> 	capable of driver hacking.

I think thats a bit unfair. Changing the description language so drastically
is the big problem, not the tools or its UI. Its 'and Im forking the config
language from under every other config tool including the kde work and mconfig'

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

[John Cowan]

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 stops you from buying a used front panel and toggling in
Linux in octal.  Oughta work the first time, too.

 

-- 
There is / one art             || John Cowan <jcowan@reutershealth.com>
no more / no less              || http://www.reutershealth.com
to do / all things             || http://www.ccil.org/~cowan
with art- / lessness           \\ -- Piet Hein

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

[Kai Germaschewski]

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 its spec sheet or consider it representative of all derivatives
>    (which may have other facilities)?
>
> I know my answer to this one, which I will implement unless there's
> strong consensus otherwise.  I go for explicitness.  If we're going to
> support MVME147 derivatives and variants in the ruleset, they get
> their own platform symbols.

I believe it's important two distinguish between two things here,
auto-configuration and normal configuration.

One should take care to not mix these things up. Of course I don't know
about the specific hardware there, but I believe selecting NVME147 will
give you arch specific code which will cope with general aspects of that
board, but also for derived designs. That makes sense, and no need to
introduce different config symbols at that level.
I'd call CONFIG symbols like that basic, and they should be described by a
ruleset which ensures that building the kernel will actually work, and
that you have a chance that it even runs. (Things like a SCSI driver
requires the SCSI midlayer, etc. which would normally lead to unresolved
symbols or the inability to load the driver module into the running kernel
later).

On the other hand, for some people it would be nice to say I've got the
reference board, build the right kernel. That's okay, but it should be
another option, and rules like that should be in a separate files, so they
don't clutter up the "basic" rulesets.

So, leave the flexibility to people who need, and on top of that you can
have a mechanism which allows easier configuration for people who don't
want to care about the details.

However, more important there would be some option like "build me a kernel
for the hardware I'm currently running on" (and let the user fine tune
afterwards).

--Kai

CML2 design philosophy heads-up

[Eric S. Raymond]

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 way: away from hardware, towards capabilities.

As a concrete example, the CML2 rulesfile master for the m68k port
tree now has a section that looks like this:

# These were separate questions in CML1.  They enable on-board peripheral
# controllers in single-board computers.
derive MVME147_NET from MVME147 & NET_ETHERNET
derive MVME147_SCC from MVME147 & SERIAL
derive MVME147_SCSI from MVME147 & SCSI
derive MVME16x_NET from MVME16x & NET_ETHERNET
derive MVME16x_SCC from MVME16x & SERIAL
derive MVME16x_SCSI from MVME16x & SCSI
derive BVME6000_NET from BVME6000 & NET_ETHERNET
derive BVME6000_SCC from BVME6000 & SERIAL
derive BVME6000_SCSI from BVME6000 & SCSI

# 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

If it isn't obvious, the intent is that if you specify (say) both 
MVME147 (a machine type) and SERIAL (a capability) you automatically 
get the specific driver support under MVME147_SCC.

This is different from the CML1 approach, which generally involved
explicitly specifying each driver with mutual dependencies described 
(if at all) in Configure.help.

I've created a number of derivations of this kind recently.  I'm not
going out of my way to do this, but what I am trying to do is reduce
the number of symbols undocumented in Configure.help to zero (I've got
it down to 243 from 547 when I started).  When I can eliminate the
need for a configuration question and associated help by writing this
kind of formula, I'm doing so.

This note is a heads-up.  If others with a stake in the configuration
system (port managers, etc.) have objections to moving further in this
direction, I need to hear about it, and about what you think we should
be doing instead.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Never could an increase of comfort or security be a sufficient good to be
bought at the price of liberty.
	-- Hillaire Belloc

Re: CML2 design philosophy heads-up

[Jes Sorensen]

>>>>> "Eric" == Eric S Raymond <esr@thyrsus.com> 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 policy or intentions.

Eric> Or to put another way: away from hardware, towards capabilities.

Eric> As a concrete example, the CML2 rulesfile master for the m68k
Eric> port tree now has a section that looks like this:

Eric> # These were separate questions in CML1.  They enable on-board
Eric> peripheral # controllers in single-board computers.  derive
Eric> MVME147_NET from MVME147 & NET_ETHERNET derive MVME147_SCC from
Eric> MVME147 & SERIAL derive MVME147_SCSI from MVME147 & SCSI derive
Eric> MVME16x_NET from MVME16x & NET_ETHERNET derive MVME16x_SCC from
Eric> MVME16x & SERIAL derive MVME16x_SCSI from MVME16x & SCSI derive
Eric> BVME6000_NET from BVME6000 & NET_ETHERNET derive BVME6000_SCC
Eric> from BVME6000 & SERIAL derive BVME6000_SCSI from BVME6000 & SCSI

Not all cards have all features, not all users wants to enable all
features.

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 thats assumption is invalid.

Eric> This is different from the CML1 approach, which generally
Eric> involved explicitly specifying each driver with mutual
Eric> dependencies described (if at all) in Configure.help.

Yes and it should stay like that. If Richard had wanted all those
features enabled per default when an MVME setting was selected, he
would have done it in the config.in file, which is perfectly valid to
do so today.

Eric> This note is a heads-up.  If others with a stake in the
Eric> configuration system (port managers, etc.) have objections to
Eric> moving further in this direction, I need to hear about it, and
Eric> about what you think we should be doing instead.  -- <a
Eric> href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Yes I have objections. I thought I had made this clear a long time
ago: Go play with another port and leave the m68k port alone.

Thank you
Jes

Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Jes Sorensen <jes@sunsite.dk>:
> 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.  It turns
on MVME147_SCSI when both MVME147 *and SCCI* are on.  So to suppress
MVME147_SCSI, one just leaves SCCI off.

All these derived symbols will still be controllable.  The difference
is that instead of being controlled by a low-level hardware-oriented
question they're controlled by a capability or subsystem symbol like
SCSI, NET_ETHERNET, or SERIAL.

> 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 thats assumption is invalid.

I'm in touch with Ray Knight directly and will fix this as he requests.
 
> Yes I have objections. I thought I had made this clear a long time
> ago: Go play with another port and leave the m68k port alone.

Does this mean you'll take over maintaining the CML2 rules files
for the m68k port, so I don't have to?  That would be wonderful.

Reasoned objections can change my behavior.  Grunting territorial
challenges at me will not.  You have two options: (1) persuade Linus
that the whole CML2 thing is a bad idea and should be dropped, or (2)
work with me to correct any errors I have made and improve the system.
Growling at me and hoping I go away won't work, not when I've invested
a year's effort in this project.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

As with the Christian religion, the worst advertisement for Socialism
is its adherents.
	-- George Orwell 

Re: CML2 design philosophy heads-up

[Jes Sorensen]

>>>>> "Eric" == Eric S Raymond <esr@thyrsus.com> writes:

Eric> Jes Sorensen <jes@sunsite.dk>:
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 thats assumption is invalid.

Eric> I'm in touch with Ray Knight directly and will fix this as he
Eric> requests.

If Ray wants to fix things, it's just fine with me.
 
>> Yes I have objections. I thought I had made this clear a long time
>> ago: Go play with another port and leave the m68k port alone.

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.

For a start, so far there has been no reason whatsoever to change the
format of definitions.

Eric> Reasoned objections can change my behavior.  Grunting
Eric> territorial challenges at me will not.  You have two options:
Eric> (1) persuade Linus that the whole CML2 thing is a bad idea and
Eric> should be dropped, or (2) work with me to correct any errors I
Eric> have made and improve the system.  Growling at me and hoping I
Eric> go away won't work, not when I've invested a year's effort in
Eric> this project.

So far you have only been irritating developers for no reason. What I
asked you to do is to NOT change whatever config options developers
developers felt were necessary to introduce. If you want to change the
format of the config.in files go ahead. Messing around with the config
options themselves is *not* for you to do, nor are you to impose a
more restrictive space for people to work in.

Jes

Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Jes Sorensen <jes@sunsite.dk>:
> 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.
> 
> For a start, so far there has been no reason whatsoever to change the
> format of definitions.

The judgment of the kbuild team is unanimous that you are mistaken on this.
That's the five people (excluding me) who wrote and maintained the CML1 code.
*They* said that code had to go, Linus has concurred with their judgment, 
and the argument is over.

> So far you have only been irritating developers for no reason. What I
> asked you to do is to NOT change whatever config options developers
> developers felt were necessary to introduce. If you want to change the
> format of the config.in files go ahead. Messing around with the config
> options themselves is *not* for you to do, nor are you to impose a
> more restrictive space for people to work in.

If you persist in misunderstanding what I am doing, you are neither
going to be able to influence my behavior nor to persuade other people
that it is wrong.  Listen carefully, please:

1. The CML2 system neither changes the CONFIG_ symbol namespace nor 
   assumes any changes in it.  (Earlier versions did, but Greg Banks
   showed me how to avoid needing to.)

2. The ruleset changes I have made simplify the configuration process,
   but they do *not* in any way restrict the space of configurations 
   that are possible.  By design, every valid (consistent) configuration
   in CML1 can be generated in CML2.  I treat departures from that rule
   as rulesfile bugs and fix them (as I just did at Ray Knight's instruction).

3. I do not have (nor do I seek) the power to "impose" anything on anyone.

You really ought to give CML2 a technical evaluation yourself before you
flame me again.  Much of what you seem to think you know is not true.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

According to the National Crime Survey administered by the Bureau of
the Census and the National Institute of Justice, it was found that
only 12 percent of those who use a gun to resist assault are injured,
as are 17 percent of those who use a gun to resist robbery. These
percentages are 27 and 25 percent, respectively, if they passively
comply with the felon's demands. Three times as many were injured if
they used other means of resistance.
        -- G. Kleck, "Policy Lessons from Recent Gun Control Research,"

Re: CML2 design philosophy heads-up

[Jes Sorensen]

>>>>> "Eric" == Eric S Raymond <esr@thyrsus.com> writes:

Eric> Jes Sorensen <jes@sunsite.dk>:
>>  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 the five people (excluding me) who
Eric> wrote and maintained the CML1 code.  *They* said that code had
Eric> to go, Linus has concurred with their judgment, and the argument
Eric> is over.

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 vendor nor does it look like they are
planning to do it anytime soon. And even if they start doing so, this
is a totally unreasonable requirement, you *must* to make it possible
to compile kernels on older distributions without requiring people to
update half of their system. On some architectures, the majority of
the users are still on glibc 2.0 and other old versions of
tools. 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. Nobody disagrees that the Makefiles needs a
redesign, however that doesn't mean everything else has to be
redisigned in a totally incompatible manner.

Eric> If you persist in misunderstanding what I am doing, you are
Eric> neither going to be able to influence my behavior nor to
Eric> persuade other people that it is wrong.  Listen carefully,
Eric> please:

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 choice", "I don't care",
"I want to hack". The majority are of the "NO!" and "you got to be
kiddin'".

Eric> 1. The CML2 system neither changes the CONFIG_ symbol namespace
Eric> nor assumes any changes in it.  (Earlier versions did, but Greg
Eric> Banks showed me how to avoid needing to.)

Let's just say you didn't exactly give peoiple a good impression with
the trolling around on how everybody had to change their option names 
and how important it was for the world.

Eric> 2. The ruleset changes I have made simplify the configuration
Eric> process, but they do *not* in any way restrict the space of
Eric> configurations that are possible.  By design, every valid
Eric> (consistent) configuration in CML1 can be generated in CML2.  I
Eric> treat departures from that rule as rulesfile bugs and fix them
Eric> (as I just did at Ray Knight's instruction).

What spawned this recent discussion was you wanting to remove config
options and automatically enable things instead of giving the users
the explicit choice to do so. Now you are trying to tell me that you
are not changing things?

Eric> 3. I do not have (nor do I seek) the power to "impose" anything
Eric> on anyone.

We'll let that one stand on display for a few minutes.

Eric> You really ought to give CML2 a technical evaluation yourself
Eric> before you flame me again.  Much of what you seem to think you
Eric> know is not true.

So far I have had to deal with a number of requests from you trying to
impose unreasonable changes on developers. Thats more than plenty for
me. I do not have Python2 installed and I do not plan to, if you
change CML2 to use a reasonable programming language I might give it a
try.

Jes

PS: And if you could start making your .signature rfc1855 compliant it
was be pleasant for all readers of this mailing list.

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

[John Cowan]

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 both python and python2
installed.  Having two different gcc versions installed is a big pain
in the arse.

> 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 choice", "I don't care",
> "I want to hack". The majority are of the "NO!" and "you got to be
> kiddin'".


Anonymized hearsay evidence is less than convincing.


> Let's just say you didn't exactly give peoiple a good impression with
> the trolling around on how everybody had to change their option names 
> and how important it was for the world.


Decidedly bad form to criticize someone for a bug (in this case,
a design bug) that's already been fixed.  If that behavior starts,
who shall escape hanging?

 
> I do not have Python2 installed and I do not plan to, if you
> change CML2 to use a reasonable programming language I might give it a
> try.


Those who don't remember the past are condemned to repeat it.

John Cowan, _novus homo_ (Latin for "upstart")

-- 
There is / one art             || John Cowan <jcowan@reutershealth.com>
no more / no less              || http://www.reutershealth.com
to do / all things             || http://www.ccil.org/~cowan
with art- / lessness           \\ -- Piet Hein

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

[Christoph Hellwig]

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
> > reasonable request.
> 
> 
> Au contraire.  It is very reasonable to have both python and python2
> installed.  Having two different gcc versions installed is a big pain
> in the arse.

Fump. Some distributions do even come with two gcc's out of the box.
With the whole egcs and gcc2.95 (dunno about 3.0) you can even share
the compiler driver if you want.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

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

[John Cowan]

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's python installation is not a
>>>reasonable request.
>>>
>>
>>Au contraire.  It is very reasonable to have both python and python2
>>installed.  Having two different gcc versions installed is a big pain
>>in the arse.
>>
> 
> Fump. Some distributions do even come with two gcc's out of the box.
> With the whole egcs and gcc2.95 (dunno about 3.0) you can even share
> the compiler driver if you want.


Yes, I should have limited myself to pre-egcs versions.

-- 
There is / one art             || John Cowan <jcowan@reutershealth.com>
no more / no less              || http://www.reutershealth.com
to do / all things             || http://www.ccil.org/~cowan
with art- / lessness           \\ -- Piet Hein

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

[Mike Castle]

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. Richard Pixley  (rich at cygnus.com)

        * configure: added -V for version number option.


mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  dalgoda@ix.netcom.com  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

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

[Christoph Hellwig]

In article <20010518101533.E10611@thune.mrc-home.com> 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 for a very
> long time.  At least since 2.0 came out.
>
> Thu Dec 19 15:54:29 1991  K. Richard Pixley  (rich at cygnus.com)
>
>         * configure: added -V for version number option.

But with at least the combination of gcc2.7.2.x and egcs1.x it did not
work for me (and others).

	Christoph

-- 
Whip me.  Beat me.  Make me maintain AIX.

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

[Jes Sorensen]

>>>>> "John" == John Cowan <jcowan@reutershealth.com> 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 reasonable request.

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.

Eric seems to think he can tell every distributor to ship Python2
tomorrow. Well it's a fine dream but it's not going to happen; Most
distributors do not ship new major versions of tools in their minor
number release versions. I've seen him mention the number 6 months
until everybody ships it, but a) thats not going to happen Red Hat is
currently at 7.1 (if one looks at their release history, one would say
there is a good chance there will be a 7.2) not to mention the release
rate of Debian (not sure about the current state of all other
distributions). 18 months is more realistic for it to be deployed
widely enough.

>> 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 choice", "I don't care", "I want to
>> hack". The majority are of the "NO!" and "you got to be kiddin'".

John> Anonymized hearsay evidence is less than convincing.

Well I don't like to quote personal conversations without peoples'
approval, now both David Woodhouse and Arjan are two examples.

Jes

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

[Mike Castle]

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
enough to install python.

mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  dalgoda@ix.netcom.com  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

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

[Ben Ford]

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 utility are going to be savvy
>enough to install python.
>
>mrc
>
Not only that, but Alan said that somebody is rewriting it in C.

-- 
 "One trend that bothers me is the glorification of
stupidity, that the media is reassuring people it's 
alright not to know anything. That to me is far more 
dangerous than a little pornography on the Internet." 
  - Carl Sagan

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

[Jes Sorensen]

>>>>> "Ben" == Ben Ford <ben@kalifornia.com> 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 that somebody is rewriting it in C.

No and yes, the Python 2 issue is not reasonable, the C version of it
is. Hopefully with a proper C version, the Python 2 dependencies will
go away completely and that part of the discussion becomes moot.

The Python 2 one is a major issue, some people compile current kernels
because thats all that exists for their hardware. Some people who are
bringing up new architectures etc. wants to be self hosting but things
like Perl and Python are not exactly the first things you build. You
may not have threads, you may not have proper math support, maybe no
shared libraries, but that wont stop you from getting
gcc/binutils/bash going. The argument I got from Eric at the 2.5
kernel summit when I first brought this up was 'just configure your
kernel on another machine and copy it over'. Thats extremely naiive,
in some cases you do not have network nor floppy. You copy your
sources over once (so you can hack on the network driver :), you don't
want to have to rip out the disk every time you need a change to the
.config because some obscure option doesn't compile and you hadn't
noticed.

It's just not that trivial.

Jes

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

[Mike Castle]

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
  dalgoda@ix.netcom.com  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

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

[Alan Cox]

> 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 ;)

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

[arjan]

In article <20010520185827.B16356@thune.mrc-home.com> 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 configuration utility are going to be savvy
> enough to install python.

In the first months, yes. Once we freeze you've just lost a major part of
your testersbase...

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

[Robert M. Love]

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
> require it.
> 
> Eric seems to think he can tell every distributor to ship Python2
> tomorrow. Well it's a fine dream but it's not going to happen; <snip>

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 expect python2 until
8.0. that wont be for 9 months.  90% of RedHat's configuration tools, et
al, are written in python1 and they just are not going to change on
someone's whim.

im not installing python2 from source just so i can run some new config
utility.

(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)

-- 
Robert M. Love
rml@ufl.edu
rml@tech9.net

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

[Jakob Østergaard]

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.
> > 
> > It's not unreasonable to have both installed, it's unreasonable to
> > require it.
> > 
> > Eric seems to think he can tell every distributor to ship Python2
> > tomorrow. Well it's a fine dream but it's not going to happen; <snip>
> 
> 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 expect python2 until
> 8.0. that wont be for 9 months.  90% of RedHat's configuration tools, et
> al, are written in python1 and they just are not going to change on
> someone's whim.

2.6.0 isn't going to happen for at least a year or two.  What's the problem ?

Want 2.5.X ?  Get the tools too.

I'm in no position to push people around, but I think the whining about CML2
tool requirements is completely unjustified.  If we required that everything
worked with GCC 2.7.2 and nmake, where would we be today ?   I'm a lot more
worried about CML2 itself than about the tools it requires   :)

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

Whether CML2 requires python2 or not, the distributions will change. This is
not about Eric pushing something down people's throats. Tools evolve, and new
revisions introduce incompatibilities, but distributions still follow the
evolution.  Nobody ships perl4 today either.

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

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

[Mike Galbraith]

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.

Alan said someone is rewriting in C, so the python2 requirement is
already becoming a non-problem.

	-Mike

(don't like requirement, but don't think it's a big hairy deal either)

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

[Jes Sorensen]

>>>>> "Jakob" == Jakob Østergaard <jakob@unthought.net> 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, RawHide. it is not using python2.  in
>> fact, since switching to python2 may break old stuff, I don't
>> expect python2 until 8.0. that wont be for 9 months.  90% of
>> RedHat's configuration tools, et al, are written in python1 and
>> they just are not going to change on someone's whim.

Jakob> 2.6.0 isn't going to happen for at least a year or two.  What's
Jakob> the problem ?

Jakob> Want 2.5.X ?  Get the tools too.

Some people grab the latest devel kernels because thats all that works
on their hardware.

Jakob> I'm in no position to push people around, but I think the
Jakob> whining about CML2 tool requirements is completely unjustified.
Jakob> If we required that everything worked with GCC 2.7.2 and nmake,
Jakob> where would we be today ?  I'm a lot more worried about CML2
Jakob> itself than about the tools it requires :)

gcc-2.7.2 is broken it miscompiles the kernel, Python1 or bash are
not.

Jakob> Whether CML2 requires python2 or not, the distributions will
Jakob> change. This is not about Eric pushing something down people's
Jakob> throats. Tools evolve, and new revisions introduce
Jakob> incompatibilities, but distributions still follow the
Jakob> evolution.  Nobody ships perl4 today either.

The point is that Eric has been trying to push distributions to ship
P2.

Jes

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

[Tom Rini]

On Mon, May 21, 2001 at 11:58:34AM +0200, Jes Sorensen wrote:
> >>>>> "Jakob" == Jakob ?stergaard <jakob@unthought.net> 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, RawHide. it is not using python2.  in
> >> fact, since switching to python2 may break old stuff, I don't
> >> expect python2 until 8.0. that wont be for 9 months.  90% of
> >> RedHat's configuration tools, et al, are written in python1 and
> >> they just are not going to change on someone's whim.
> 
> Jakob> 2.6.0 isn't going to happen for at least a year or two.  What's
> Jakob> the problem ?
> 
> Jakob> Want 2.5.X ?  Get the tools too.
> 
> Some people grab the latest devel kernels because thats all that works
> on their hardware.

And they can grab the latest tools too.  Why is this a problem again?
python1.5.x is compatiable w/ python2 EXCEPT in the cases where the script
uses undocumented things which did work in python1.5.x.  But that's not as
big of a problem since they can co-exist.  Debian already does this (And thus
CML2 already deals with python2 being called 'python2') and I wouldn't be
supprised if the PowerTools python2 rpm someone pointed out makes them
co-exist as well.

Which brings up another point, RedHat (7.1?) and Debian/woody both have the
option of having python2 around.  Anyone know about mandrake?  My point is
that some dists are already dealing with python2.

> Jakob> I'm in no position to push people around, but I think the
> Jakob> whining about CML2 tool requirements is completely unjustified.
> Jakob> If we required that everything worked with GCC 2.7.2 and nmake,
> Jakob> where would we be today ?  I'm a lot more worried about CML2
> Jakob> itself than about the tools it requires :)
> 
> gcc-2.7.2 is broken it miscompiles the kernel, Python1 or bash are
> not.

Well no, but python1 requires another 2k lines of python code or so.
Eric, would it be easy/possible to go back to requiring python 1.5.x for
CML2, since that is what many dists ship with?

> Jakob> Whether CML2 requires python2 or not, the distributions will
> Jakob> change. This is not about Eric pushing something down people's
> Jakob> throats. Tools evolve, and new revisions introduce
> Jakob> incompatibilities, but distributions still follow the
> Jakob> evolution.  Nobody ships perl4 today either.
> 
> The point is that Eric has been trying to push distributions to ship
> P2.

Maybe, maybe not.  Forgetting about the QA time and whatnot, there's good
odds that all of the python scripts RedHat (for example) ships will just
work with python2.  I know one of the PPC dists didn't ship with python2
(which does have a lot of python bits to it) entirely because they were
already in testing when it came out.  It's not something the distros
can switch to at a whim, but it's also something which shouldn't cause
them problems when they do.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

[Eric S. Raymond]

Tom Rini <trini@kernel.crashing.org>:
> 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 CML2's in-kernel footprint
substantially.

> Which brings up another point, RedHat (7.1?) and Debian/woody both have the
> option of having python2 around.  Anyone know about mandrake?  My point is
> that some dists are already dealing with python2.

Yes.  By the time 2.5 forks, distros covering an estimated 85% of the market
will carry python2 binaries which the CML2 install script will find 
automatically.  By the time 2.6 forks, we're going to laugh if we ever
remember that we thought this was an issue.

> Eric, would it be easy/possible to go back to requiring python 1.5.x for
> CML2, since that is what many dists ship with?

It wouldn't be too difficult.  But it would make the code heavier, and
I'm not clear that it would make anybody happy who isn't already willing
to deal with the design concept.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The world is filled with violence. Because criminals carry guns, we
decent law-abiding citizens should also have guns. Otherwise they will
win and the decent people will lose.
        -- James Earl Jones

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

[Mike A. Harris]

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 expect python2 until
>8.0. that wont be for 9 months.  90% of RedHat's configuration tools, et
>al, are written in python1 and they just are not going to change on
>someone's whim.
>
>im not installing python2 from source just so i can run some new config
>utility.
>
>(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)

powertools/7.1/SRPMS/python2-2.0-3.src.rpm

For the record, the kgcc "mess" you speak of was used by
Conectiva, and I believe also by debian before adoption in Red
Hat Linux.  It was about as good a solution as one could get for
the problem that it solved - the kernel being broken and unable
to build with our gcc-2.96.  Just to head anyone off at the
pass... the kernel is fixed and now builds properly with
gcc-2.96.  Also, if anyone has any questions about gcc-2.96
please see:

http://www.bero.org/gcc296.html

----------------------------------------------------------------------
    Mike A. Harris  -  Linux advocate  -  Open Source advocate
       Opinions and viewpoints expressed are solely my own.
----------------------------------------------------------------------
Microsoft Windows(tm). A 32 bit extension and graphical shell to a 16 bit 
patch to an 8 bit operating system originally coded for a 4 bit microprocessor
which was written by a 2 bit company that can't stand 1 bit of competition.

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

[Robert M. Love]

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" you speak of was used by
> Conectiva, and I believe also by debian before adoption in Red
> Hat Linux.  It was about as good a solution as one could get for
> the problem that it solved - the kernel being broken and unable
> to build with our gcc-2.96.  Just to head anyone off at the
> pass... the kernel is fixed and now builds properly with
> gcc-2.96.

my view of the mess wasn't the fact RedHat used kgcc. i think that was a
good move.

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
binary because my python1 binary is my "standard" python?

-- 
Robert M. Love
rml@ufl.edu
rml@tech9.net

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

[Alan Cox]

> 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

Problem 3:
	People who don't like the tool design

Problem 4:
	People who don't have python2 


#1 is the important item
#2 is fixed by rewriting tools in C
#3 is fixed by writing alternative tools using CML2 - and if you cant its a bug
   in the CML2 language
#4 is probably one for the LDPS/LSB and vendor people to discuss so we have an
official path for python2

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

[Brent D. Norris]

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

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

[Eric S. Raymond]

Brent D. Norris <brent@biglinux.tccw.wku.edu>:
> 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.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

A wise and frugal government, which shall restrain men from injuring
one another, which shall leave them otherwise free to regulate their
own pursuits of industry and improvement, and shall not take from the
mouth of labor the bread it has earned. This is the sum of good
government, and all that is necessary to close the circle of our
felicities.
	-- Thomas Jefferson, in his 1801 inaugural address

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

[Wichert Akkerman]

In article <Pine.LNX.4.33.0105210205520.1590-100000@asdf.capslock.lan>,
Mike A. Harris <mharris@opensourceadvocate.org> 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.

-- 
  _________________________________________________________________
 /       Nothing is fool-proof to a sufficiently talented fool     \
| wichert@cistron.nl                  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |
-- 
  _________________________________________________________________
 /       Nothing is fool-proof to a sufficiently talented fool     \
| wichert@cistron.nl                  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

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

[Alan Cox]

> Mike A. Harris <mharris@opensourceadvocate.org> 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

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

[Alexander Viro]

On 21 May 2001, Wichert Akkerman wrote:

> In article <Pine.LNX.4.33.0105210205520.1590-100000@asdf.capslock.lan>,
> Mike A. Harris <mharris@opensourceadvocate.org> 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 used as a kernel compiler
for quite a while and gcc-2.95 being used the same way in -testing.

<shrug> having different compilers for kernel and userland is not
pretty, but there's no way to avoid it at some points in cycle.

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

[Nicolas Pitre]

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.
>
> Eric seems to think he can tell every distributor to ship Python2
> tomorrow. Well it's a fine dream but it's not going to happen

Distributors aren't going to ship Linux 2.5.x tomorrow either.


Nicolas

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

[Steven Cole]

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 vendor nor does it look like they are
> planning to do it anytime soon. And even if they start doing so, this

Actually, Linux-Mandrake 8.0 ships with Python 2.0, but your next
point is a very good one:

> is a totally unreasonable requirement, you *must* to make it possible
> to compile kernels on older distributions without requiring people to
> update half of their system. On some architectures, the majority of
> the users are still on glibc 2.0 and other old versions of
> tools. 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. Nobody disagrees that the Makefiles needs a
> redesign, however that doesn't mean everything else has to be
> redisigned in a totally incompatible manner.

I didn't have trouble installing python 2.0 before LM 8.0 did that for me,
but I was probably just lucky.  I've seen some reports by other people who
did have difficulty upgrading python.  If the python installation difficulties
are a real obstacle, perhaps that is what needs to be fixed.

Steven

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

[Steven Cole]

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 mandrake?  My
> > > point is that some dists are already dealing with python2.
> >
> > Hi Tom,
> > I use Linux-Mandrake 8.0 now, and python2 is installed by default for a
> > development workstation installation.  I asked Mandrakesoft to also
> > install the tkinter package (which was not installed by default in
> > release candidate 1), and it appeared in LM 8.0 final, so if you like to
> > use make xconfig with CML2, you can.
>
> Could you please send this to linux-kernel as well? :)

At Tom's request, posting to lkml.
Steven