Date: Mon, 12 Apr 1999 20:41:19 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Alfred Perlstein <bright@rush.net> Cc: Peter Wemm <peter@netplex.com.au>, cvs-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: sys/pci pci.c Message-ID: <Pine.BSF.4.05.9904122039220.74823-100000@herring.nlsystems.com> In-Reply-To: <Pine.BSF.3.96.990412135448.4169P-100000@cygnus.rush.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 12 Apr 1999, Alfred Perlstein wrote: > 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). That sounds very worthwhile. While you are at it, can you try to factor out the common code from the i386 and alpha ports so that both can use the new mechanism. > > 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? This is possibly material for the current list (although personally I don't mind reading it here). -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9904122039220.74823-100000>