On Tue, 2008-12-23 at 10:09 -0500, Nathaniel McCallum wrote:
> I've been working on it up until recently. The main wall that I've
> hit is that NMDevice assumes that the "device" (whatever that means;
> in bluetooth land, its not so clear) lifecycle is greater than the
> NMDevice lifecycle and that the device exists in HAL. I've not really
> found a way around that, but perhaps dcbw would like to comment...
>
> Nathaniel
Hello Nathaniel, list!
I'm working for a company[1] and I've been given a project in which I
can work with NetworkManager. Oh, the joy! :)
I haven't had the permission to discuss anything work related in public
until now, but I'm very eager to co-operate with others to make NM rock
even harder.
I am currently working on Bluetooth support among other things. I'm
looking at Dial-up Networking (DUN) and Personal Area Networking (PAN).
I have priority on DUN and I heard on #nm that someone is already
working on PAN which is great news!
With PAN I think is clear that a completely new device class should be
created. That's fine. Someone who is working with PAN should write to
the list, so that the discussion gets documented and archived.
DUN on the other hand can not be made as a new device class as it's just
a way to get a serial device for NMGsmDevice and NMCdmaDevice. It would
be clear to separate NMSerialDevice to NMHalSerialDevice,
NMBluetoothSerialDevice, and NMPathSerialDevice (for arbitrary paths
like '/dev/ttyS0' or '/dev/foo/bar/proprietary69'), but because
NMGsmDevice and NMCdmaDevice are derived directly from NMSerialDevice we
can't do the split; that would lead to NMBluetoothGsmDevice,
NMHalGsmDevice, NMHalCdmaDevice, etc and also break the current device
type enumeration.
Instead I suggest that we handle the different serial types inside
NMSerialDevice. Let's add a 'type' option to serial configuration.
NMSerialDevice would then handle these different types internally. The
different types would be specified as an enumeration like {hal,
bluetooth, path, irda, ...} The option would be optional and default to
HAL.
When a SettingsService signals a new GSM or CDMA connection with serial
type set to 'bluetooth' NM would create the device object. Then the
connection could be activated from nm-applet. Upon activation
NM(SerialDevice) would ask BlueZ to create a bluez device object, query
for DUN service on the remote device, and create a RFCOMM serial port.
When the connection gets disconnected the RFCOMM port and BlueZ device
object would be closed and released. When connection settings are
deleted in SettingsService the device object would be destroyed.
Comments, suggestions?
Let's get this ball moving!
-- Antti
PS.
you also reach me on #nm, I'm 'Wellark'
[1] http://www.nomovok.com
Attachment:
signature.asc
Description: This is a digitally signed message part