[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Adding KAUTH_DEVICE_TTY_ATTACH_<TYPE>
On Wed, Apr 29, 2009 at 9:24 PM, Iain Hibbert <plunky%rya-online.net@localhost>
> 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
>> 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, 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 stack rather than
> out of the tty node.
>  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)
>  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
> That would likely work
To summarize, then, we need KAUTH_NETWORK_INTERFACE::ADD + ::ENABLE
(or similar) in ppp, and two more ::ENABLEs in sl/strip. We also need
KAUTH_DEVICE_BLUETOOTH_ADD + ENABLE for btuart/bcsp.
Sounds good? :)
Main Index |
Thread Index |