Replacing/enhancing kernel printf()
Marcel Moolenaar
xcllnt at mac.com
Sat Sep 22 11:42:36 PDT 2007
On Sep 19, 2007, at 10:15 PM, Poul-Henning Kamp wrote:
> In message <8697991F-F97B-4D19-8712-91162AFA5A66 at 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 at mac.com
More information about the freebsd-arch
mailing list