On Tue, 2005-12-13 at 01:57 +0000, Keir Fraser wrote:
> On 12 Dec 2005, at 22:00, Alex Williamson wrote:
>
> > You're right, but it's not quite that easy. I think we need some
> > consistency checking here. The point of this function seems to be
> > determining if the driver owns the device. If so, set the index and
> > return the driver, otherwise pass. I think the patch below does a
> > better job of solving the problem. When xc_num == c->index, the device
> > is the port xencons created, so the index is 0 and we claim it. The
> > only slightly complicated one is when using the tty devices c->index is
> > zero when xc_num is 1. I believe this does the right thing in all
> > cases, let me know what you think. Thanks,
>
> What I would like to know is what the two index values actually mean.
> :-) That is, what is c->index, and what is the index value that is
> returned? Without knowing this I have no idea whether your patch is
> correct or not. Is the expected behaviour of that console driver hook
> function understood and/or documented?
I've had to do a bit more homework myself to rationalize these
changes, but I think I have a fuzzy idea how it all fits together. We
start by creating a list of console_cmdlines via
add_preferred_console(). This function is called for each console= boot
option on the command line. The console_cmdline list stores the name,
index and option for each console option, with the last entry being the
preferred console. In this context, the index is the entry into the
global address space for the name of the device. For instance, ttyS1 is
name "ttyS", index 1.
Later on in boot, xen_console_init() calls register_console(). This
goes through the list of console_cmdlines looking for matches. The
console structure that xen_console_init() passes in uses an index value
of -1. The interpretation of values < 0 is that this driver claims all
indexes of the given name. I suspect this is not what we want since the
xen console driver only handles a single port. In this case, the name
is matched and the index value specified on the command line is copied
into the console structure. The console structures are added to the
console_drivers list in LIFO order with the exception that the preferred
console is always at the head of the list.
Even later in boot, the tty half of the xen console driver gets
started via xencons_init(). Here a tty driver and tty device are
registered and where we get to the other kind of index. The device is
registered as index zero into the array or devices this particular tty
driver claims. This indicates the device lives at the major and
minor_start values specified by the tty driver.
Finally, we get to the point where we want to open /dev/console.
tty_open() calls console_device() looking for a tty driver and tty
index. console_device() starts at the head of the console_drivers list
(the preferred console) and calls the console->device() function. The
device function needs to return the tty driver associated with this
device, and set the index to the offset of the device within the array
of tty devices the driver claims.
As you can see, the xen console driver is a little bit unique here.
Most drivers have their own range of devices they claim and the tty
index is identical to the device file index. For us, the tty index is
always zero regardless of the device file index. Based on this
understanding of how it all works, I think the below patch is sufficient
to solve the problem and allow us to move xencons around to device
numbers other than ttyS0 and tty1. Hopefully that clears up the index
confusion. Thanks,
Alex
Signed-off-by: Alex Williamson <alex.williamson@xxxxxx>
---
diff -r 53cff3f88e45 linux-2.6-xen-sparse/drivers/xen/console/console.c
--- a/linux-2.6-xen-sparse/drivers/xen/console/console.c Fri Dec 9
11:05:06 2005
+++ b/linux-2.6-xen-sparse/drivers/xen/console/console.c Tue Dec 13
13:18:00 2005
@@ -168,7 +168,7 @@
static struct tty_driver *kcons_device(struct console *c, int *index)
{
- *index = c->index;
+ *index = 0;
return xencons_driver;
}
@@ -212,6 +212,8 @@
default:
return __RETCODE;
}
+
+ kcons_info.index = xc_num;
wbuf = alloc_bootmem(wbuf_size);
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home