linux-kernel - Re: How do I choose an arbitrary minor number for my tty device?

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]

Message-ID: <20101118112146.3275eb08@udp111988uds.am.freescale.net>
Date:	Thu, 18 Nov 2010 11:21:46 -0600
From:	Scott Wood <scottwood@...escale.com>
To:	Timur Tabi <timur@...escale.com>
CC:	Greg KH <gregkh@...e.de>, Arnd Bergmann <arnd@...db.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Stuart Yoder <stuart.yoder@...escale.com>
Subject: Re: How do I choose an arbitrary minor number for my tty device?

On Thu, 18 Nov 2010 10:03:12 -0600
Timur Tabi <timur@...escale.com> wrote:

> I'm not so sure.  Like I said, I still don't see where there's a bus.  I have a
> single driver that has multiple devices.  It sounds to me like one call to
> tty_register_driver() and multiple calls to tty_register_device() would be
> sufficient.
> 
> For instance, there is no code in drivers/char/ that makes a call to
> bus_register(), so I don't see any precedent for a tty driver to register a bus
> first.

The tty driver doesn't register the bus, but rather a driver for
some type of device on that bus.  The code to create the bus goes
elsewhere, and would not be specific to byte channels.

> Also, this is an Open Firmware driver.  I already have a mechanism whereby I get
> probed for each instance of a byte channel.  Isn't that my "bus"?

It would be if you actually had it -- but it looks like you just loop
over the nodes.

We should add a proper bus for the "handles" node.  Then sysfs should
show the link between the tty device and a device tree node -- which is
really what we're after, the handle is just a means to that end.

> I'm really trying to do the right thing here, Greg, but every time I try to
> solve one problem, I'm being told that I need to make things way more
> complicated first.

s/make things way more complicated/use the existing infrastructure
rather than reinvent the wheel/

And getting rid of the redundant chardev driver would be a
simplification...

-Scott

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