Re: [PATCH 4/6] drivers:misc: sources for Init manager module

Pavan Savoy
2010-03-24T17:05:27Z

--- On Wed, 24/3/10, Greg KH <gregkh@suse.de> wrote:

> From: Greg KH <gregkh@suse.de>
> Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
> To: "Pavan Savoy" <pavan_savoy@yahoo.co.in>
> Cc: "Marcel Holtmann" <marcel@holtmann.org>, "PavanSavoy" <pavan_savoy@ti.com>, "alan@lxorguk.ukuu.org.uk" <alan@lxorguk.ukuu.org.uk>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
> Date: Wednesday, 24 March, 2010, 10:22 PM
> On Wed, Mar 24, 2010 at 10:05:19PM
> +0530, Pavan Savoy wrote:
> > --- On Wed, 24/3/10, Greg KH <gregkh@suse.de>
> wrote:
> >
> > > From: Greg KH <gregkh@suse.de>
> > > Subject: Re: [PATCH 4/6] drivers:misc: sources
> for Init manager module
> > > To: "Marcel Holtmann" <marcel@holtmann.org>
> > > Cc: "Pavan Savoy" <pavan_savoy@yahoo.co.in>,
> "PavanSavoy" <pavan_savoy@ti.com>,
> "alan@lxorguk.ukuu.org.uk"
> <alan@lxorguk.ukuu.org.uk>,
> "linux-kernel@vger.kernel.org"
> <linux-kernel@vger.kernel.org>
> > > Date: Wednesday, 24 March, 2010, 9:56 PM
> > > On Wed, Mar 24, 2010 at 09:11:45AM
> > > -0700, Marcel Holtmann wrote:
> > > > > I wanted to somehow put this in staging
> because
> > > then it would probably have a thorough
> architectural review
> > > process.
> > > > > Some details about this driver -
> > > > >
> > > > > 1. This driver will be used by
> > > Bluetooth-BlueZ/FM-V4L2 and GPS (probably
> character device
> > > driver) using the EXPORTED symbols
> (-register/_unregister).
> > > > >
> > > > > 2. Much like the hciattach daemon which
> maintains
> > > N_HCI bluetooth line discipline, this driver will
> also have
> > > a User-Space? N_TI_WL Init manager (UIM)
> maintaining
> > > the Line discipline.
> > > >
> > > > can you explain why you think this is needed
> and we
> > > can not interface
> > > > this directly. If it is a serial port, what
> protocol
> > > does it talk?
> > > >
> > > > > 3. Because of the UIM should know when
> to
> > > install/uninstall line discipline, the /sys entry
> is created
> > > a root called UIM (a new kobject) and UIM daemon
> would write
> > > it's PID to it.
> > > >
> > > > I don't understand this. This sounds like a
> broken
> > > concept to me.
> > >
> > > I also agree, those sysfs files are not
> acceptable, and
> > > will not work
> > > as-designed due to the pid namespace issues :(
> >
> > Ok, How do I then from kernel space, ask a user-space
> daemon to open the TTY port and do a tiocsetd on it ?
> > [i.e ask for a line discipline to be installed ?]
>
> What would cause the kernel to want to tell userspace to do
> this?  Is it
> an external event that happens somehow that userspace
> should know to
> look for?

Yes, Userspace events like opening the /dev/radio0 device for FM, or hci0 interface for BT.
However the apps/stack would not want to know what LDISC is being used underneath, well they might not even want to know whether it's TTY or USB/i2C - right ?

> > Can't open the TTY and TIOCSETD upon boot, because BT,
> FM and GPS
> > might be used or not used anytime.
>
> What causes them to want to be used?  The user,
> right?
>
> > And the idea of creating a device node, specifically
> for this and then
> > doing an fasync/SIGIO was somehow rubbished.
>
> Why?

It does pretty much the same thing, But we would be stuffing in more interfaces to the already huge driver.
I mean just 3 fops on the device ? open/ioctl-fasync/close - but it also uses the SIGnaling concept - but not via PID though.

Alan's talking about opening up the LDISC installation to kernel (say EXPORTING tty_set_ldisc/tiocsetd), That's like ideal scenario in this case.

>
> thanks,
>
> greg k-h
>

The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/