All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@hp.com>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [PATCH] xencons missing string allocation
Date: Tue, 13 Dec 2005 13:44:11 -0700	[thread overview]
Message-ID: <1134506652.11473.102.camel@localhost> (raw)
In-Reply-To: <d16ae565c310a878d84911d729509b8e@cl.cam.ac.uk>

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@hp.com>
---

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);

  reply	other threads:[~2005-12-13 20:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-09 18:37 [PATCH] xencons missing string allocation Alex Williamson
2005-12-09 18:54 ` Muli Ben-Yehuda
2005-12-09 20:37   ` Alex Williamson
2005-12-10  0:00     ` Alex Williamson
2005-12-10 15:06       ` Keir Fraser
2005-12-10 16:27         ` Alex Williamson
2005-12-10 23:12           ` Keir Fraser
2005-12-12 22:00             ` Alex Williamson
2005-12-13  1:57               ` Keir Fraser
2005-12-13 20:44                 ` Alex Williamson [this message]
2005-12-13 21:00                   ` Keir Fraser
2005-12-12  9:40 ` Tristan Gingold

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1134506652.11473.102.camel@localhost \
    --to=alex.williamson@hp.com \
    --cc=Keir.Fraser@cl.cam.ac.uk \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.