From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 24 13:12:58 2018 Received: (at 30604) by debbugs.gnu.org; 24 Mar 2018 17:12:58 +0000 Received: from localhost ([127.0.0.1]:51673 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ezmiv-0004C4-UJ for submit@debbugs.gnu.org; Sat, 24 Mar 2018 13:12:58 -0400 Received: from hera.aquilenet.fr ([185.233.100.1]:53978) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ezmiu-0004Bw-9O for 30604@debbugs.gnu.org; Sat, 24 Mar 2018 13:12:56 -0400 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id B70B11184B; Sat, 24 Mar 2018 18:12:55 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at aquilenet.fr Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvmMvJ9da-Dn; Sat, 24 Mar 2018 18:12:54 +0100 (CET) Received: from ribbon (vpn-0-27.aquilenet.fr [IPv6:2a0c:e300:4:27::]) by hera.aquilenet.fr (Postfix) with ESMTPSA id 9D82D116E8; Sat, 24 Mar 2018 18:12:54 +0100 (CET) From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) To: Danny Milosavljevic Subject: Re: Keyboard detection before =?utf-8?B?4oCYY3J5cHRzZXR1cOKAmQ==?= runs References: <87h8plkkkc.fsf@gnu.org> <20180312221541.1886-1-ludo@gnu.org> <20180312221541.1886-5-ludo@gnu.org> <87fu54fjfj.fsf@gnu.org> <87o9jlo28l.fsf@inria.fr> <20180323140231.1c96615c@scratchpost.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 4 Germinal an 226 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Sat, 24 Mar 2018 18:12:52 +0100 In-Reply-To: <20180323140231.1c96615c@scratchpost.org> (Danny Milosavljevic's message of "Fri, 23 Mar 2018 14:02:31 +0100") Message-ID: <87h8p5jt2j.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 30604 Cc: 30604@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) Heya, Danny Milosavljevic skribis: > I have to say what we have to do is much more complicated than I thought > it would be - and I kinda regret starting this patchset. I didn't > want to make it less likely for people to boot than before :-( Yeah, I had a nightmare where I dreamed of all the bug reports due to devices not showing up quickly enough. :-) > A small bit of research shows that: > > - Busybox uses a loop with timeout to try to mount over and over again, > depending on bus type [2]. > - Alpine coldplugs twice [1]. > - Fatdog has a "waitdev" boot parameter that specifies how long it sleeps > until it tries to mount the root. > - Redhat mkinitrd has an mkinitrd option like "--with=3Dscsi_wait_scan" w= hich > they use after they saw a modalias starting with "scsi:" - or add the > kernel option "scsi_mod.scan=3Dsync" to the command line [3] (but they sa= y that > this is unreliable now and one is supposed to use udev inside the initrd). > Not sure what they do for USB. > > The Linux kernel itself has a "rootdelay" parameter which > was specifically introduced because of USB devices that took 15 s (!) > to show up. It=E2=80=99s a kludge fest, which is reassuring, in a way. > All in all, we have alternative ways to continue: > > (a) Drop this patchset/feature entirely because it's too unreliable. > (b) Monitor /sys using inotify in an extra thread/process. > (c) Include udev into the initrd and have it do its thing. > (d) Monitor the netlink socket in our own thread and play udev ourselves. > (e) Find out how to, for each bus type, detect when enumeration is finish= ed. > Find out which buses are there. Wait for them to finish enumerating. > (f) Always modprobe usb-hid first, no matter what. I think this would > become a whack-a-mole thing fast. > > I'd prefer either (a) or (b) for reliability and simplicity. WDYT? Same here! Sounds like (b) is something we could easily try, though we won=E2=80=99t know how well it works until people start running it on the b= are metal. I can adjust the branch I have to do that and push it for people to try. Thanks a lot of your feedback! Ludo=E2=80=99.