linux-kernel - Re: [PATCH 1/3] TTY: add support for "tty slave" devices.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 5 Jan 2015 20:09:36 +1300
From:	NeilBrown <neilb@...e.de>
To:	Pavel Machek <pavel@....cz>
Cc:	Grant Likely <grant.likely@...aro.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Mark Rutland <mark.rutland@....com>,
	Jiri Slaby <jslaby@...e.cz>, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] TTY: add support for "tty slave" devices.

On Sun, 4 Jan 2015 11:18:47 +0100 Pavel Machek <pavel@....cz> wrote:

> Hi!
> 
> > > > +Optional child node:
> > > > +- a platform device listed as a child node will be probed and
> > > > +  powered-on whenever the tty is in use (open).
> > > > +
> > > >  Example:
> > > >  
> > > >  	uart@...30000 {
> > > 
> 
> > But some line disciplines don't really want the char_dev.
> > N_MOUSE wants a serio device.
> > N_HCI wants an HCI device
> > N_GSM07010 wants 63 different tty char_devs.
> > N_IRDA and N_PPP ultimately want a net_dev.
> > etc.
> > 
> > It would be really nice if the uart would register the line disciple as a
> > child device, then the line discipline would register whatever it wants.
> 
> Yes.
> 
> > N_HCI activates (registers the hci dev) on HCIUARTSETPROTO ioctl.  A child
> >   device would need a way to specify the protocol I resume.
> > N_MOUSE activates on a 'read' on the tty - and deactivates when the read
> >   completes.
> > N_GSM0710 activates immediately that the ldisc is activated, as does N_IRDA
> > N_PPP seems to want a PPPIOCNEWUNIT ioctl to fully register.
> > 
> > Doing any of these in a driver for a uart slave device would certainly be
> > possible.  I wonder if it is something we really want to do in the kernel
> > though.  What is the gain over providing sufficient information in the
> > KOBJ_ADD uevent so that udev can do the required work in user-space?
> 
> Consistency. If you have bluetooth on USB, it automatically works,
> without userspace help. If we have mouse on USB, it automatically
> works, etc...

My point is: why is the kernel/userspace distinction important?  As long as
it "automatically works", does it really matter where the code is?
We can put a little bit of code in the kernel (to report the details of the
attached device) and a little bit of code in udev (to run hciattach) and it
will still be automatic.

NeilBrown


> 
> > However I do like the idea of having the UART probe the child instead of
> > registering a tty.  It could pass the tty_operations structure to the child,
> > and the child could then register a tty with a slightly different
> > tty_operations structure, allowing it to capture any operations that it wants
> > to capture (such as open/close).
> > I might try coding that and see what it looks like...
> 
> Lets have a look...
> 									Pavel


Content of type "application/pgp-signature" skipped