From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261712AbUEEDWo (ORCPT ); Tue, 4 May 2004 23:22:44 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261779AbUEEDWo (ORCPT ); Tue, 4 May 2004 23:22:44 -0400 Received: from fw.osdl.org ([65.172.181.6]:27049 "EHLO mail.osdl.org") by vger.kernel.org with ESMTP id S261712AbUEEDWi (ORCPT ); Tue, 4 May 2004 23:22:38 -0400 Date: Tue, 4 May 2004 20:21:06 -0700 From: "Randy.Dunlap" To: "Patrick J. LoPresti" Cc: greg@kroah.com, linux-kernel@vger.kernel.org Subject: Re: Load hid.o module synchronously? Message-Id: <20040504202106.106529b3.rddunlap@osdl.org> In-Reply-To: References: <408D65A7.7060207@nortelnetworks.com> <20040504200147.GA26579@kroah.com> <20040504223550.GA32155@kroah.com> Organization: OSDL X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On 04 May 2004 22:49:56 -0400 "Patrick J. LoPresti" wrote: | Greg KH writes: | | > On Tue, May 04, 2004 at 05:56:48PM -0400, Patrick J. LoPresti wrote: | > | > > But what if it fails to bind? For example, what if an error occurs? | > > Or what if the keyboard is on the module's blacklist? How do I know | > > when to stop waiting? | > | > You do not, sorry. | | That is disappointing. I mean, I deal with Microsoft products a lot, | where "unreliable by design" is normal. But I expected better from | Linux. It's just a different model than what you are looking for. The hid (or whatever) driver supports a hotplug environment. It cannot know what device(s) are expected to be present or just which ones you are looking for. If it's a huge problem, you have the source code, modify the driver to do what you want it to do. | > > Ideally, what I would like is for "modprobe " to wait | > > until all hardware handled by that driver is either ready for use | > > or is never going to be. That seems simple and natural to me. | > | > Sorry, but this is not going to happen. It does not fit into the | > way the kernel handles drivers anymore. Again, sorry. | | OK, an arbitrary flaky delay it is. Thanks! -- ~Randy