Date: Sat, 22 Sep 2007 11:41:15 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: arch@freebsd.org Subject: Re: Replacing/enhancing kernel printf() Message-ID: <FED4C690-E501-4F54-93AE-F5B75929BBA6@mac.com> In-Reply-To: <5708.1190265356@critter.freebsd.dk> References: <5708.1190265356@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 19, 2007, at 10:15 PM, Poul-Henning Kamp wrote: > In message <8697991F-F97B-4D19-8712-91162AFA5A66@mac.com>, Marcel > Moolenaar wri > tes: >> >> On Sep 19, 2007, at 12:25 PM, Poul-Henning Kamp wrote: >> >>> >>>> What do people think of such an ability? >>> >>> You should re-read the "consoled revisited" post I made to arch@ >>> some time ago, there are a couple of details you overlook. >> >> Are you referring to: >> http://lists.freebsd.org/mailman/htdig/freebsd-arch/2006-May/ >> 005224.html > > Yes. Ok. Let's throw it in. Try this on for size: Let's define "the low-level console" as nothing more than a switchboard. It conceptually has sources and sinks and by means of an as of yet undefined method allows connecting sources to 0 or more sinks. Sources and sinks are as of yet undefined KOBJ interfaces (but let's assume for now that they match the CONS_DRIVER/CONSOLE_DRIVER interface). Let's define "the console" as the console device (i.e. /dev/console), which is nothing more than a conduit between the file/tty layer and the low-level console (aka switchboard) as connects as a source. Let's assume that opening the console will create a new instance and thus a new independent source into the switchboard. At least that seems to me to be a good idea now :-) Now, back to my original posting. We define printf(9) a source into the switchboard. But, I proposed that we want more fine-grained control over what gets "printed" where. In other words, we want printf(9) to behave as if it was connected as multiple sources, each configured with its own set of sinks. Another way of looking at it is by borrowing from USB: Each sources/sink is device and each device can have multiple endpoints. We create pipes between endpoints and the low-level console operates on pipes. Unlike USB pipes in this context can have multiple endpoint sinks. Without going deeper and into more detail: would such a concept be a good basis to work things out? Some examples to make it less abstract: o cninit() initializes the low-level console (i.e. the switchboard. It will register the CONS_DRIVER set as sinks and will create some initial (set of) sources. Depict this as working the same as we have now, just with some conceptual differences. It is possible that no sinks exist initially, which probably means that everything coming in from sources gets discarded. As a default we can connect all sources to all sinks? o The msgbuf will eventually be created and in the new world order, will become an independent sink. This could be the only sink, which means that everything gets "printed" to the msgbuf. By default we connect all sources to the msgbuf? o /sbin/init will eventually open /dev/console, which becomes a new source and by some undefined means will be connected to sinks. Maybe all sinks? o If, say, we have a serial console (in the current scheme of things), we typically also spawn getty(8) on the corresponding device special file. Opening the device special should in some undefined way affect the low-level console, because the serial port may also have been registered as a sink by way of being a CONS_DRIVER. Removing the corresponding CONS_DRIVER from the low-level console seems like the right thing to do. Thoughts? -- Marcel Moolenaar xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FED4C690-E501-4F54-93AE-F5B75929BBA6>