Re: Adding KAUTH_DEVICE_TTY_ATTACH_<TYPE>

[Iain Hibbert <plunky%rya-online.net@localhost>]

On Wed, 29 Apr 2009, Elad Efrat wrote:

> On Tue, Apr 28, 2009 at 11:37 PM, Iain Hibbert 
> <plunky%rya-online.net@localhost> wrote:
> > On Tue, 28 Apr 2009, Elad Efrat wrote:
> >> Why should we call it "create a pseudo device"?
> >
> > In the ppp case, when you run a program that wants to open a PPP
> > connection it creates a new network interface as if an actual network card
> > had just been plugged in. Hence a pseudo device is created. Same for the
> > bluetooth code and I think its somewhat cleaner that way.
>
> Hm: are you sure the code in net/ppp_tty.c adds a network interface?
> from its commit message:
>
>     The PPP kernel code is now split into if_ppp.c, containing generic
> PPP support, and ppp_tty.c, which specifically supports PPP on async
> tty devices (as a line discipline).

Well: setting the line discipline causes the .l_open function to be
called. In this case its pppopen() which calls pppalloc() which calls
ppp_create() which creates the new network interface..

(there seems another path where pppalloc() doesn't call ppp_create() but I
think its a special case where a transfer of ownership is arranged using
the PPPIOCXFERUNIT ioctl and I'm not sure how that is used exactly,
perhaps just to offload the IO to another process inside pppd(8) and I
think its reasonable to expect the other process to have sufficient
credentials)

> If it adds a network interface, we should be using something like
> KAUTH_NETWORK_INTERFACE::ADD, but I want to make sure we're not mixing
> two functionalities of the same device. :)
>
> As for the bluetooth code, bcsp and btuart, aren't they doing the
> same? the man page suggests they're used to implement a tty over
> btuart/bcsp, which is what lead me to classify them under the "tty"
> category in the first place...

No, they provide a "tty line discipline" which controls what happens to
the IO from the serial port which already exists and is attached to a
/dev/ttyXX node.

What happens is that if the admin determines that a bluetooth controller
with RS232C interface is attached to the serial port[1], they can manually
configure a bluetooth device in the system as there is no way to
autoconfigure a device on a serial line.. and then, the raw IO will be
passed directly into the bottom end of the bluetooth[2] stack rather than
out of the tty node.

[1] often the serial port is contained inside the device rather than it
    actually having an external RS232C lead. This is the case for several
    PCMCIA/CF devices which attach as com(4)

[2] or the network stack, in the sl(4), strip(4) and ppp(4) cases.

> > Although the sl(4) and strip(4) instances (currently) need to be 'created'
> > beforehand, it is the act of attaching the line discipline that actually
> > turns an inactive interface to an active one. Perhaps that requires more
> > than just a single authorisation step (create => activate => configure)?
>
> Suppose we do that, sl/strip get just one authorization call
> ("activate"), and the rest (ppp, btuart, bcsp) get two ("create" and
> "activate")?

That would likely work

regards,
iain