Messages in this thread | | | From | "Savoy, Pavan" <> | Date | Thu, 7 Oct 2010 20:22:32 +0530 | Subject | RE: [PATCH 1/2] drivers:staging:ti-st: move TI_ST from staging |
| |
> -----Original Message----- > From: Jiri Slaby [mailto:jirislaby@gmail.com] > Sent: Thursday, October 07, 2010 2:59 AM > To: Savoy, Pavan > Cc: gregkh@suse.de; linux-kernel@vger.kernel.org; devel@driverdev.osuosl.org; > alan@lxorguk.ukuu.org.uk > Subject: Re: [PATCH 1/2] drivers:staging:ti-st: move TI_ST from staging > > On 10/07/2010 12:36 AM, Savoy, Pavan wrote: > >>>>> +int st_core_init(struct st_data_s **core_data) > >>>>> +{ > >>>>> + struct st_data_s *st_gdata; > >>>>> + long err; > >>>>> + static struct tty_ldisc_ops *st_ldisc_ops; > >>>>> + > >>>>> + /* populate and register to TTY line discipline */ > >>>>> + st_ldisc_ops = kzalloc(sizeof(*st_ldisc_ops), GFP_KERNEL); > >>>>> + if (!st_ldisc_ops) { > >>>>> + pr_err("no mem to allocate"); > >>>>> + return -ENOMEM; > >>>>> + } > >>>> This can be static structure, you don't need to allocate this on heap. > >>>> It should be a singleton. > >>> > >>> Yes, I got this comment before, but is it just a style issue? > >>> I want to keep this in heap because some day, I hope TTY ldics have their > >> own > >>> private_data, which I can pass around like the tty_struct's data. > >>> and having them in heap, I plan to keep a reference to ops structure, so > >> that I > >>> can pass around and use ops->private_data everywhere .. > >> > >> I doubt ldisc ops will ever have ->private_data. What would you need it > >> for? The ops generally work with ttys which have ->disc_data. > > > > Yes, But in this case, I required something which can be set during > ldisc_register, and can be picked up during tty_open. > > Why? ldiscs are per-system, singletons, not per-device. So you should > not bind to them any device specific info.
Per-system? I don't understand this. There can be ldisc for each individual TTY, so doesn't that make it per device? Or to be even more specific, it makes it per-TTY which is mapped to a particular device, UART/a-set of usb-endpoints etc...
This driver in fact does just that, it is a driver which allows sharing of the TTY by many other drivers (I call it the protocol drivers).
> -- > js
| |