> Hello,
>
> > The consoel does need more work than that. Since the console system was
> > designed for one head than the code was naturally SMP safe. When you have
> > SMP and a multiheaded system you have the change of two heads running at
> > the same time.
>
> If the old locking scheme were correct, it would be enough to add a simple
> spinlock to all the places where we lock against console_bh. Unfortunately,
> the current locking scheme is incorrect as it completely ignores the fact
> anybody can use printk() from an interrupt. We finally need to handle it
> somehow.
Yippe. I never though about that race condition. That is a really bad
problem.
> > This can run into severe problems. Also what do you do for
> > systems that have two framebuffers and one keyboard. Or two keyboards and
> > one framebuffer.
Taking a look at it.
> My early attempts on this can be found in Vojtech's patches. They work
> this way:
>
> o Each keyboard has its own `struct keyboard' containing a bitmap
> of consoles it can be switched to.
> o Each logical console is mapped to one physical display (VGA
> screen, a framebuffer etc.) represented by `struct display'
> (screen blanking etc. works on displays).
> o At each moment, each keyboard send its output to a single
> console chosen from its `allowed consoles' bitmap. Pressing
> Alt+Fn switches the keyboard to the console chosen and brings
> the console to the front at the display it's connected to.
----------------------------------------------------------------------------
> Another possibility is to forget the assignment bitmaps and define heads
> instead. Each head has a bunch of keyboards, mice (and other input devices)
> and consoles assigned and only one of the consoles is active and it's written
> to by all the keyboards. It can be easier to think of and to use, but the
> possibilities of the first model are much wider -- you can for example define
> `global keyboard' which has access to all the consoles and so on.
IMO thats the way to go. From my experience with fbdev that moving the
console code from the fbdev drivers into fbcon reduced the code and made
driver writing very easy. Less code of course means less bugs and less
race conditions. In fbdev the fb_info structure represents the current
state of the framebuffer device. This is of course the state of the
video hardware of the active console. Of course fbdev doesn't know
anything about the console but fbcon does know about fbdev. So fbcon grabs
fbdev hardware info (colormap, video mode) to handle console
operations. Now fbcon keeps a data structure (struct display) for each
VT. When a VT switch happens fbcon saves the state of the video hardware
at the time of the VT switch. Then it sets the hardware to the state the
new console was just before the VT switch from it.
So having the console system handle device state when VT switching will
greatly reduce code and make drivers much simpler. Drivers of any
kind don't need to know anything about the console system. The console
system does need to know about the hardware state. Its just would be nice
to have single consistent API to handle console to hardware driver
interface.
Now for the global, head, and VT handling. As I stated moving console
handling code from hardware drivers into console handling code will
greatly reduce code and complexity. Now the console system has to be
able to see the hardware state. We also want to have exterme
flexiablity to handle all kinds of cases like 3 keyboards and systems with
one video display. You could have a tree like structure to handle how much
the device state influences the console system.
system +-> head 1 +-> vt 1
| +-> vt 2
| ...
|
+-> head 2 +-> vt 10
With this we can attach input and output devices anywhere in the tree. As
for things like "global" keyboards. Now if you have only one keyboard, you
can just attach it at "system" into the tree and it will be global for all
consoles. When you attach the second one, and attach it to head 2,
keyboard 1 will send to both heads, keyboard 2 will only work on head
2. Of course you will probably rather attach one at head 1 and the other at
head 2, but take this example. You have classroom full of students. The
master head the teacher would use and the students would have their own
head. The teacher head would have the global keyboard. So if the student
do something stupid the teacher can still get in to recover. Here the
state of the hardware on the system level influences the entire
system. For the students their heads would only influence their consoles
(active and non active). What about two keyboards attached to one
head. Here we can attach keyboard A to certain VTs and keyboard B to the
rest of the VTs. At boot time we can have all the kernel output displayed
to "system" so it shows up on all the terminals. What would be really nice
is even have the printer as a display. This way when I'm testing a fbdev
driver and it doesn't work I can send output to my printer to see whats
going on. As you can see this can be very flexiable.
> > Their is need to support 16 bit characters so you can display asian
> > languages.
>
> Do we really want the kernel console to do this? I think such things belong
> to user-space programs like xterm. Having full UniCode fonts in the kernel
> is a bit too much.
Yes. I know if I was korean I would want this. If you are thinking that
I'm suggesting having every kanji symbol built in thats wrong. We
actually had a discussion on this in the fbdev list. I know japanese and I
know that about 1000 kanji are normally used in everyday life. So we need
to have loaded the standard kanji. Add the rest as needed. If you look
threw the fbdev mail archives you will see this discuss and what to do to
handle it. Their is link to the mailing list at www.linux-fbdev.org. I
don't remember when we had the discussion.
James Simmons (o_
fbdev/gfx developer (o_ (o_ //\
http://www.linux-fbdev.org (/)_ (/)_ V_/_
http://linuxgfx.sourceforge.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/