In-Reply-To: <20090128204705.7140d5fd@lxorguk.ukuu.org.uk>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 60/80] tty: extract the pty init time special cases
MIME-Version: 1.0
Message-ID: <OFD0116D1D.5061D2AB-ON8525754D.005C6317-8525754D.00661977@perle.com>
From: bmckinlay@perle.com
Date: Thu, 29 Jan 2009 13:30:26 -0500
Content-Type: text/plain; charset="US-ASCII"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3489
Lines: 93

> > my driver to be a module instead of statically linked with the kernel 
like
> > pty is.

> Sure - although it might make more sense to add any neede features to 
the
> generic pty driver - hard to tell when you don't seem interested in
> discussing that.

It's not necessarily that I'm not interested but more that I'm a little
reluctant to do it for the following reasons:

The unknown:
  - have never personally submitted anything to the kernel, need to find 
out 
    what the requirements are, how much documentation you need etc
  - no guarantee how long this will take and that my submission will even 
be 
    accepted.  The longer it takes the more kernel releases that will be
    released where my driver no longer works
Loss of control:
  - my ptyx driver is just one part of the product, it has a daemon part 
and
    of coarse configurators. If the driver is put in the kernel then we 
lose
    the guarantee that a customer will be using compatible versions of 
these 
    3 parts of the product.  Now they are all packaged together
Work involved: 
  - my current ptyx driver is conditionally compiled up the whazoo since 
it 
    works on 2.2.x, 2.4.x and 2.6.x kernels.  Will have to pull out the 
2.6.x
    specific code in order to submit it.
  - will have to add the driver to the kernel config as a configurable 
module
  - any required documentation explaining how the driver works and 
describing
    the API for the master side of the PTY driver ?
  - actually creating the patch and submitting it.

> > By not exporting these symbols it means that the Linux kernel is now
> > forcing anyone who wants to develop a PTY type TTY driver to be merged 

> > into the kernel tree by not exporting these TTY functions. This 
doesn't 
> > seem very "open and flexible".

> No you can provide the GPL symbol exports with the same patch as your 
pty
> driver. There are millions of Linux users and each unused EXPORT_SYMBOL
> costs memory to all those people - why should they carry that burden ?

Given the fact that it in this day and age it is unaceptable to require 
customers to recompile their kernel in order to use a new driver I beleive
my point was lost here.  I was referring to "out of kernel tree" driver
development.
I'll explain my point another way.
As mentioned above the Linux kernel has supported "out of tree" PTY type 
TTY 
drivers all the way back to kernel 2.2.x and up to 2.6.27. To do this the 
kernel exports symbols like 
  - alloc_tty_driver(), tty_set_operations() or tty_register_driver() used 

    in TTY driver's module init functions
  - tty_hangup() used in driver close operations/methods
  - tty_insert_flip_char() or tty_flip_buffer_push() used in ioctl 
    operations/methods.
  - tty_unregister_driver() used in TTY driver module exit functions
 
Now in this patch it was decided to push some of the PTY specific logic 
from 
tty_init_dev() down to the PTY driver by introducing a new install method 
for
PTY drivers.  This new install method for the PTY driver needs to allocate 
the
slave's TTY and initialize it but the TTY functions required to do this 
were not
exported.
All I'm asking is for the Linux kernel to maintain it's support for "out 
of tree" 
PTY type drivers.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/