Re: Bluetooth support

[Dan Williams <dcbw redhat com>]

On Fri, 2008-12-26 at 23:35 +0200, Antti Kaijanmäki wrote:
> 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.

Or, make the GSM and CDMA bits GInterfaces instead that any particular
device can implement...  That's the cleaner route actually.

Dan

> 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
> 
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list