[CRIU] [PATCH 1/6] tty: Rework tty_driver structure

[Cyrill Gorcunov]

On Thu, Apr 02, 2015 at 06:28:37PM +0300, Pavel Emelyanov wrote:
> On 04/02/2015 06:12 PM, Cyrill Gorcunov wrote:
> > On Thu, Apr 02, 2015 at 06:04:41PM +0300, Pavel Emelyanov wrote:
> >>
> >>> @@ -182,19 +180,16 @@ static struct tty_driver ptm_driver = {
> >>>  static int open_simple_tty(struct tty_info *info);
> >>>  
> >>>  static struct tty_driver console_driver = {
> >>> -	.t			= TTY_TYPE_CONSOLE,
> >>> -	.flags			= TTY_MASTER,
> >>> +	.type			= TTY_TYPE__CONSOLE,
> >>> +	.subtype		= TTY_SUBTYPE_SLAVE,
> >>
> >> Why slave? This breaks some codepaths below.
> > 
> > Which one it breaks? 
> 
> The pty_alloc_fake_reg(), but it looks like it's not called for CONSOLE.

pty_alloc_fake_reg called for pty peers only and not for console.

> > The console is a slave by definition.
> 
> O_o   What's the definition?

The console is a system device, the programs can only open it but
not "create" on its own. The kernel in turn uses this abstraction
to put some driver under it (tty or whatever) and write kernel
messages into. So a program can open it and read/write into but
unlike ptys there is no such thing as master/slave peer as far
as I understand. IOW program does not create system console
but may use one granted by a system.

int __init tty_init(void)
{
	...
	cdev_init(&console_cdev, &console_fops);
	if (cdev_add(&console_cdev, MKDEV(TTYAUX_MAJOR, 1), 1) ||
	    register_chrdev_region(MKDEV(TTYAUX_MAJOR, 1), 1, "/dev/console") < 0)
		panic("Couldn't register /dev/console driver\n");
	consdev = device_create(tty_class, NULL, MKDEV(TTYAUX_MAJOR, 1), NULL,
			      "console");

See, the kernel generates this abstaction (which simply reserves a few
numbers in chardev space). Then the kernel can undrlie some driver under
this console

#ifdef CONFIG_VT
	vty_init(&console_fops);
#endif
	return 0;

so that all operations over /dev/console device gonna be redirected
to VT driver. But again, note that we're not creating new console
it's granted us by a system, we only use it. So that's why I
conside it as a slave. It won't hurt actually if I drop this bit ;)

> 
> > If you mean tty_is_master() helper then it's different
> > context -- it means we don't have to open master peer
> > for it, and because the console is special and the program
> > only has one peer of it (always) that's why it is slave
> > by nature but "master" in terms of criu.
> 
> OK, let's assume it's such. Why isn't VT slave then? Maybe not
> assign _any_ types on both and keep them for PTYs only?

VT is... erm... I didn't dive much into VT kernel's code but
in the form as it now it should work well. And I think yes,
maybe indeed better to keep them for PTYs... May I create
patch on top instead?