[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081207180302.339bf58d@lxorguk.ukuu.org.uk>
Date: Sun, 7 Dec 2008 18:03:02 +0000
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Evgeniy Polyakov <zbr@...emap.net>
Cc: Kay Sievers <kay.sievers@...y.org>,
Herbert Xu <herbert@...dor.apana.org.au>,
linux-kernel@...r.kernel.org,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: Runaway loop with the current git.
On Sun, 7 Dec 2008 20:54:38 +0300
Evgeniy Polyakov <zbr@...emap.net> wrote:
> On Sun, Dec 07, 2008 at 05:52:45PM +0000, Alan Cox (alan@...rguk.ukuu.org.uk) wrote:
> > > Alan, let's make some progress on this fingerpointing. If Herbert's
> > > patch fixes the crypto loading problem, it will find its way upstream
> > > for the current tree, and in the merge window Kay's patch may be applied
> > > and widely tested. Thoughts?
> >
> > I have no intention of applying Kay's patch because it is wrong and it
> > will only break things not fix them.
>
> And you are sure it breaks something based on what?
Firstly:
You propose to implement
modprobe fails (due to crypto requirements)
open /dev/console
-ENODEV
log error to nowhere
Why is this useful - you now get failing module loads producing no
diagnostics and in many case the setup just dying silently. Previously
you got an attempt to recover and diagnostics which allowed the problem
to be found (as Herbert did)
Secondly:
If I have a /dev/console on a PCI device and I have modprobe set to load
8250_pci or a framebuffer driver when the console is opened you will
break the current working behaviour.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists