From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: [PATCH] xencons missing string allocation Date: Tue, 13 Dec 2005 13:44:11 -0700 Message-ID: <1134506652.11473.102.camel@localhost> References: <1134153451.6136.14.camel@tdi> <20051209185448.GD9830@granada.merseine.nu> <1134160653.6463.6.camel@tdi> <1134172824.6952.6.camel@tdi> <1134232041.23367.21.camel@localhost.localdomain> <78ef4b0c9258d4fa7788fce3e3a5287b@cl.cam.ac.uk> <1134424851.5523.9.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel List-Id: xen-devel@lists.xenproject.org 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 --- 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);