Re: Brown-paper-bag bug in m68k, sparc, and sparc64 config files

Re: Brown-paper-bag bug in m68k, sparc, and sparc64 config files

[Benedict Bridgwater]

> This bug unconditionally disables a configuration question -- and it's
> so old that it has propagated across three port files, without either
> of the people who did the cut and paste for the latter two noticing it.
>
> This sort of thing would never ship in CML2, because the compiler
> would throw an undefined-symbol warning on BLK_DEV_ST.  The temptation
> to engage in sarcastic commentary at the expense of people who still
> think CML2 is an unnecessary pain in the butt is great.  But I will
> restrain myself.  This time.

So a shortcoming of the CML1 tools justifies the CML2 language?

I guess the next bug found in the Python2 interpreter will justify
writing CML3 in FORTRAN.

Ben

Re: Brown-paper-bag bug in m68k, sparc, and sparc64 config files

[Miles Lane]

On 19 May 2001 21:06:51 -0400, Benedict Bridgwater wrote:
> > This bug unconditionally disables a configuration question -- and it's
> > so old that it has propagated across three port files, without either
> > of the people who did the cut and paste for the latter two noticing it.
> >
> > This sort of thing would never ship in CML2, because the compiler
> > would throw an undefined-symbol warning on BLK_DEV_ST.  The temptation
> > to engage in sarcastic commentary at the expense of people who still
> > think CML2 is an unnecessary pain in the butt is great.  But I will
> > restrain myself.  This time.
> 
> So a shortcoming of the CML1 tools justifies the CML2 language?
> 
> I guess the next bug found in the Python2 interpreter will justify
> writing CML3 in FORTRAN.

IIRC, Eric floated the CML2 idea over a year ago, provided some
rudimentary code and requested feedback.  There has seemed, for a long
time, to be agreement amoungst most kernel developers that there were
serious problems with CML1 and that it needed to be junked. There are
many things that CML1 was not going to allow us to do that will be
possible with CML2 (subsetting of the code tree, etc). I don't think
Eric's statement about this particular brown-paper-bag bug means that he
thinks that this alone justifies migrating to CML2. There are a lot of
good reasons for the migration. It isn't, perhaps, a perfect solution,
but it is one that Eric has implemented with a year's worth of effort,
with full knowledge of the kernel development community and with an open
invitation for contributions and feedback. To rag on it now seems
belated and unhelpful. It would be more useful if you helped Eric
improve CML2, since there appears to be agreement that it will be used
in 2.5.

	Miles

Re: Brown-paper-bag bug in m68k, sparc, and sparc64 config files

[Ben Bridgwater]

Miles Lane wrote:
> 
> On 19 May 2001 21:06:51 -0400, Benedict Bridgwater wrote:
> > > This bug unconditionally disables a configuration question -- and it's
> > > so old that it has propagated across three port files, without either
> > > of the people who did the cut and paste for the latter two noticing it.
> > >
> > > This sort of thing would never ship in CML2, because the compiler
> > > would throw an undefined-symbol warning on BLK_DEV_ST.  The temptation
> > > to engage in sarcastic commentary at the expense of people who still
> > > think CML2 is an unnecessary pain in the butt is great.  But I will
> > > restrain myself.  This time.
> >
> > So a shortcoming of the CML1 tools justifies the CML2 language?
> >
> > I guess the next bug found in the Python2 interpreter will justify
> > writing CML3 in FORTRAN.
> 
> IIRC, Eric floated the CML2 idea over a year ago, provided some
> rudimentary code and requested feedback.  There has seemed, for a long
> time, to be agreement amoungst most kernel developers that there were
> serious problems with CML1 and that it needed to be junked. There are
> many things that CML1 was not going to allow us to do that will be
> possible with CML2 (subsetting of the code tree, etc). I don't think
> Eric's statement about this particular brown-paper-bag bug means that he
> thinks that this alone justifies migrating to CML2. There are a lot of
> good reasons for the migration. It isn't, perhaps, a perfect solution,
> but it is one that Eric has implemented with a year's worth of effort,
> with full knowledge of the kernel development community and with an open
> invitation for contributions and feedback. To rag on it now seems
> belated and unhelpful. It would be more useful if you helped Eric
> improve CML2, since there appears to be agreement that it will be used
> in 2.5.

Well if Eric is so concerned about his target audience then he certainly
doesn't show it through his arrogant comments. CML2 itself may be well
justified (although not on grounds of a diagnostic that CML1 tools could
be changed to generate!), but there's no reason the tools utilizing the
CML2 based rules shouldn't present a *superset* of the existing
functionality. To present a dumbed down UI targeted for "Aunt Millie" or
whoever against the protests of the mainstream kernel tool audience
makes zero sense to me, as don't Eric's repeated antagonistic comments.

Ben

Re: Brown-paper-bag bug in m68k, sparc, and sparc64 config files

[Keith Owens]

On Sat, 19 May 2001 22:14:33 -0400, 
Ben Bridgwater <bennyb@ntplx.net> wrote:
>To present a dumbed down UI targeted for "Aunt Millie" or
>whoever against the protests of the mainstream kernel tool audience
>makes zero sense to me, as don't Eric's repeated antagonistic comments.

How many times do we have to say this?  CML2 supports everybody from
Aunt Millie (novice mode) through non-standard machine configurations
(expert mode) through Linus (vi .config, make oldconfig).  Pick the
level of configuration that you need.

Re: Brown-paper-bag bug in m68k, sparc, and sparc64 config files

[Miles Lane]

On 19 May 2001 21:06:51 -0400, Benedict Bridgwater wrote:
> > This bug unconditionally disables a configuration question -- and it's
> > so old that it has propagated across three port files, without either
> > of the people who did the cut and paste for the latter two noticing it.
> >
> > This sort of thing would never ship in CML2, because the compiler
> > would throw an undefined-symbol warning on BLK_DEV_ST.  The temptation
> > to engage in sarcastic commentary at the expense of people who still
> > think CML2 is an unnecessary pain in the butt is great.  But I will
> > restrain myself.  This time.
> 
> So a shortcoming of the CML1 tools justifies the CML2 language?
> 
> I guess the next bug found in the Python2 interpreter will justify
> writing CML3 in FORTRAN.

IIRC, Eric floated the CML2 idea over a year ago, provided some
rudimentary code and requested feedback.  There has seemed, for a long
time, to be agreement amoungst most kernel developers that there were
serious problems with CML1 and that it needed to be junked. There are
many things that CML1 was not going to allow us to do that will be
possible with CML2 (subsetting of the code tree, etc). I don't think
Eric's statement about this particular brown-paper-bag bug means that he
thinks that this alone justifies migrating to CML2. There are a lot of
good reasons for the migration. It isn't, perhaps, a perfect solution,
but it is one that Eric has implemented with a year's worth of effort,
with full knowledge of the kernel development community and with an open
invitation for contributions and feedback. To rag on it now seems
belated and unhelpful. It would be more useful if you helped Eric
improve CML2, since there appears to be agreement that it will be used
in 2.5.

	Miles

Brown-paper-bag bug in m68k, sparc, and sparc64 config files

[Eric S. Raymond]

This bug unconditionally disables a configuration question -- and it's
so old that it has propagated across three port files, without either
of the people who did the cut and paste for the latter two noticing it.

This sort of thing would never ship in CML2, because the compiler
would throw an undefined-symbol warning on BLK_DEV_ST.  The temptation
to engage in sarcastic commentary at the expense of people who still
think CML2 is an unnecessary pain in the butt is great.  But I will
restrain myself.  This time.

--- arch/m68k/config.in	2001/05/19 21:36:57	1.1
+++ arch/m68k/config.in	2001/05/19 21:37:12
@@ -192,7 +192,7 @@
       int  'Maximum number of SCSI disks that can be loaded as modules' CONFIG_SD_EXTRA_DEVS 40
    fi
    dep_tristate '  SCSI tape support' CONFIG_CHR_DEV_ST $CONFIG_SCSI
-   if [ "$CONFIG_BLK_DEV_ST" != "n" ]; then
+   if [ "$CONFIG_CHR_DEV_ST" != "n" ]; then
       int  'Maximum number of SCSI tapes that can be loaded as modules' CONFIG_ST_EXTRA_DEVS 2
    fi
    dep_tristate '  SCSI CD-ROM support' CONFIG_BLK_DEV_SR $CONFIG_SCSI
--- arch/sparc/config.in	2001/05/19 21:34:54	1.1
+++ arch/sparc/config.in	2001/05/19 21:35:21
@@ -162,7 +162,7 @@
 
    dep_tristate '  SCSI tape support' CONFIG_CHR_DEV_ST $CONFIG_SCSI
 
-   if [ "$CONFIG_BLK_DEV_ST" != "n" ]; then
+   if [ "$CONFIG_CHR_DEV_ST" != "n" ]; then
       int  'Maximum number of SCSI tapes that can be loaded as modules' CONFIG_ST_EXTRA_DEVS 2
    fi
 
--- arch/sparc64/config.in	2001/05/19 21:37:33	1.1
+++ arch/sparc64/config.in	2001/05/19 21:37:45
@@ -146,7 +146,7 @@
 
    dep_tristate '  SCSI tape support' CONFIG_CHR_DEV_ST $CONFIG_SCSI
 
-   if [ "$CONFIG_BLK_DEV_ST" != "n" ]; then
+   if [ "$CONFIG_CHR_DEV_ST" != "n" ]; then
       int  'Maximum number of SCSI tapes that can be loaded as modules' CONFIG_ST_EXTRA_DEVS 2
    fi
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Conservatism is the blind and fear-filled worship of dead radicals.

Re: Brown-paper-bag bug in m68k, sparc, and sparc64 config files

[Mike Galbraith]

On Sat, 19 May 2001, Eric S. Raymond wrote:

> This bug unconditionally disables a configuration question -- and it's
> so old that it has propagated across three port files, without either
> of the people who did the cut and paste for the latter two noticing it.
>
> This sort of thing would never ship in CML2, because the compiler
> would throw an undefined-symbol warning on BLK_DEV_ST.  The temptation
> to engage in sarcastic commentary at the expense of people who still
> think CML2 is an unnecessary pain in the butt is great.  But I will
> restrain myself.  This time.

Erm.. if this bug is _that old_ and nobody noticed, isn't the right
fix to just delete the dead option?

	-Mike