> Horst von Brand <[EMAIL PROTECTED]>:
> > If you support broken configurations in any way, your program is just
> > wildly guessing what they did mean. The exact (and very probably not in any
> > way cleanly thought out) behaviour in corner cases then becomes "the way
> > things work", and we
Horst von Brand <[EMAIL PROTECTED]>:
>> No. Every new kernel changes the constraints so every new kernel you have
>> to reconfigure from scratch. That also makes it very hard to be sure you got
>> the results right.
>
> Really? I've mostly seen symbols added, very rarely did I see constraints
>
Horst von Brand <[EMAIL PROTECTED]>:
> If you support broken configurations in any way, your program is just
> wildly guessing what they did mean. The exact (and very probably not in any
> way cleanly thought out) behaviour in corner cases then becomes "the way
> things work", and we end up in an
> "horst" == Horst von Brand <[EMAIL PROTECTED]> writes:
Hi
horst> Hell, I had to rebuild my .config files from scratch a few times already
horst> because of wild changes in the hardware on which the resulting kernels
horst> would have to run, its not _that_ big a deal to have to perhaps
Alan Cox <[EMAIL PROTECTED]> said:
> In-Reply-To: <[EMAIL PROTECTED]> from "Horst von
> *** Brand" at May 03, 2001 08:32:07 AM
> > > No, we're just asking you to make the CML2 parser more tolerant of old
> > > and possibly broken configs.
> > It is _much_ easier on everybody involved to
> > No, we're just asking you to make the CML2 parser more tolerant of old
> > and possibly broken configs.
>
> It is _much_ easier on everybody involved to just bail out and ask the user
> (once!) to rebuild the configuration from scratch starting from the defaults.
No. Every new kernel
John Stoffel <[EMAIL PROTECTED]> said:
[...]
> No, we're just asking you to make the CML2 parser more tolerant of old
> and possibly broken configs.
It is _much_ easier on everybody involved to just bail out and ask the user
(once!) to rebuild the configuration from scratch starting from the
Horst von Brand [EMAIL PROTECTED]:
No. Every new kernel changes the constraints so every new kernel you have
to reconfigure from scratch. That also makes it very hard to be sure you got
the results right.
Really? I've mostly seen symbols added, very rarely did I see constraints
changed.
No, we're just asking you to make the CML2 parser more tolerant of old
and possibly broken configs.
It is _much_ easier on everybody involved to just bail out and ask the user
(once!) to rebuild the configuration from scratch starting from the defaults.
No. Every new kernel changes the
Horst von Brand [EMAIL PROTECTED]:
If you support broken configurations in any way, your program is just
wildly guessing what they did mean. The exact (and very probably not in any
way cleanly thought out) behaviour in corner cases then becomes the way
things work, and we end up in an
Horst von Brand [EMAIL PROTECTED]:
If you support broken configurations in any way, your program is just
wildly guessing what they did mean. The exact (and very probably not in any
way cleanly thought out) behaviour in corner cases then becomes the way
things work, and we end up in an
John Stoffel [EMAIL PROTECTED] said:
[...]
No, we're just asking you to make the CML2 parser more tolerant of old
and possibly broken configs.
It is _much_ easier on everybody involved to just bail out and ask the user
(once!) to rebuild the configuration from scratch starting from the
horst == Horst von Brand [EMAIL PROTECTED] writes:
Hi
horst Hell, I had to rebuild my .config files from scratch a few times already
horst because of wild changes in the hardware on which the resulting kernels
horst would have to run, its not _that_ big a deal to have to perhaps have to do
Eric> Giacomo Catenazzi <[EMAIL PROTECTED]>:
>> No. You propmt only one invalid assertion. After you this prompt
>> you continue to validate rules and you will maybe prompt for another
>> invalid rules. But these invalid rules are generally infrequent.
Eric> I may be having problems with your
Giacomo Catenazzi <[EMAIL PROTECTED]>:
> No. You propmt only one invalid assertion. After you this prompt
> you continue to validate rules and you will maybe prompt for another
> invalid rules. But these invalid rules are generally infrequent.
I may be having problems with your English. I
"Eric S. Raymond" wrote:
>
> Giacomo A. Catenazzi <[EMAIL PROTECTED]>:
> > My proposal is instaed of complain about configuration violatation,
> > you just wrote the possible correct configuration and prompt user to
> > select the correct configuration.
> > In the case you cite, e.g. oldconfig
Giacomo Catenazzi [EMAIL PROTECTED]:
No. You propmt only one invalid assertion. After you this prompt
you continue to validate rules and you will maybe prompt for another
invalid rules. But these invalid rules are generally infrequent.
I may be having problems with your English. I don't
Eric S. Raymond wrote:
Giacomo A. Catenazzi [EMAIL PROTECTED]:
My proposal is instaed of complain about configuration violatation,
you just wrote the possible correct configuration and prompt user to
select the correct configuration.
In the case you cite, e.g. oldconfig shoud prompt:
Eric Giacomo Catenazzi [EMAIL PROTECTED]:
No. You propmt only one invalid assertion. After you this prompt
you continue to validate rules and you will maybe prompt for another
invalid rules. But these invalid rules are generally infrequent.
Eric I may be having problems with your English.
On Tue, May 01, 2001 at 05:35:12PM -0400, Olivier Galibert wrote:
> On Tue, May 01, 2001 at 12:31:12PM -0400, Eric S. Raymond wrote:
> > You are proposing an interface that will handle easy cases but blow
> > up in the user's face in any hard one. That's poor design, frustrating
> > the user
On Tue, May 01, 2001 at 12:31:12PM -0400, Eric S. Raymond wrote:
> You are proposing an interface that will handle easy cases but blow
> up in the user's face in any hard one. That's poor design, frustrating
> the user exactly when he/she most needs help.
Yeah, but what is the current method,
Giacomo A. Catenazzi <[EMAIL PROTECTED]>:
> I think that a fundamental requirment is that 'make oldconfig' should
> validate any configurations (also the wrong conf).
> (If you correct your rules, our old .config can be invalid on a new
> kernel, and we don't want regualary edit our .config).
"Eric S. Raymond" wrote:
>
> Peter Samuelson <[EMAIL PROTECTED]>:
> > [esr]
> > > Besides, right now the configurator has a simple invariant. It will
> > > only accept consistent configurations
> >
> > So you are saying that the old 'vi .config; make oldconfig' trick is
> > officially
Eric S. Raymond wrote:
Peter Samuelson [EMAIL PROTECTED]:
[esr]
Besides, right now the configurator has a simple invariant. It will
only accept consistent configurations
So you are saying that the old 'vi .config; make oldconfig' trick is
officially unsupported? That's too bad,
On Tue, May 01, 2001 at 12:31:12PM -0400, Eric S. Raymond wrote:
You are proposing an interface that will handle easy cases but blow
up in the user's face in any hard one. That's poor design, frustrating
the user exactly when he/she most needs help.
Yeah, but what is the current method, vi?
On Tue, May 01, 2001 at 05:35:12PM -0400, Olivier Galibert wrote:
On Tue, May 01, 2001 at 12:31:12PM -0400, Eric S. Raymond wrote:
You are proposing an interface that will handle easy cases but blow
up in the user's face in any hard one. That's poor design, frustrating
the user exactly
Giacomo A. Catenazzi [EMAIL PROTECTED]:
I think that a fundamental requirment is that 'make oldconfig' should
validate any configurations (also the wrong conf).
(If you correct your rules, our old .config can be invalid on a new
kernel, and we don't want regualary edit our .config).
27 matches
Mail list logo
