From owner-cvs-all Mon Apr 12 11:54:29 1999 Delivered-To: cvs-all@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id 26F6A155C0; Mon, 12 Apr 1999 11:54:06 -0700 (PDT) (envelope-from bright@rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id OAA28985; Mon, 12 Apr 1999 14:04:59 -0500 (EST) Date: Mon, 12 Apr 1999 14:04:58 -0500 (EST) From: Alfred Perlstein To: Peter Wemm Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: sys/pci pci.c In-Reply-To: <19990412081343.473391F4F@spinner.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk On Mon, 12 Apr 1999, Peter Wemm wrote: > Alfred Perlstein wrote: > > > -= New-bus architecture repository =- > [..] > > I haven't looked at the code yet but was wondering if there is any > > provision for pre-probing devices. > > > > specifically i'm interested in fixing the console stuff to be more > > modular ie. allocating a device for input and another for output for > > different subsystems specifically system console, DDB and GDB seperatly, > > it seems like after this new code i will have to start from scratch, > > i'm just hoping there will be a way to do this and to notify a device > > that it has already been probed or allocated for something else. > > > > is this possible? > > Hmm.. I'm not quite sure what it is that you're trying to do, but I'll > mention a couple of things that might help: > > 1: probing is easy. You just tell the root of the tree to probe, and it > and all the children do whatever is required. > 2: reprobing.. detecting if things have gone away.. I don't know about > that. Removing children could probably be made to notify back up the > tree, and in the console case, trigger a reprobe. I don't know. > 3: we have not touched the "console" mechanism, although a root device > for a console so that console drivers could attach to it could > probably work. The problem that i faced was that the console stuff must be done even before the SYSINITs are done it's generally setup from machdep.c this is before a lot of stuff is really setup. How early can i expect this framework to be in place so i can attach a console bus/device or does it seem i have to hack this somehow? What i'm planning on is a way to modularize the console code enough so that during runtime the console can be moved from device to device and even support a forked console (i/o on both sio and sc) revoking a console and a split console (input serial, output syscons). thanks, -Alfred btw, i'm not familiar with the proper way to use this list, am i generating noise by cc'ing the list or is that the proper way, or should move messages like this to -current? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message