On Sun, Dec 7, 2008 at 19:03, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote: > On Sun, 7 Dec 2008 20:54:38 +0300 > Evgeniy Polyakov <zbr@xxxxxxxxxxx> wrote: > >> On Sun, Dec 07, 2008 at 05:52:45PM +0000, Alan Cox (alan@xxxxxxxxxxxxxxxxxxx) 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 Yes, log nowhere instead of running in a loop would be much better than loading a 5:1 driver which will never exist as a module. > Why is this useful - you now get failing module loads producing no > diagnostics and in many case the setup just dying silently. It's obviously more useful than not to boot up. > 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. No, the pci driver will never get loaded by modprobe 5:1, that's all what this bug is about. It connects to the existing console device when the driver is loaded, and at that moment /dev/console gets working. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
