On Wed, 2009-01-14 at 12:27 -0500, Dan Williams wrote:
> On Tue, 2009-01-13 at 19:11 +0200, Antti Kaijanmäki wrote:
<snip>
> > Now we are focusing on GSM and CDMA so there are NMGsmInterface and
> > NMCdmaInterface which pretty much contain the code currently present in
> > NMGsmDevice and NMCdmaDevice. Then there are corresponding
> > NMBluetoothGsmDevice, NMDeviceKitGsmDevice, NMBluetoothCdmaDevice and
> > NMDeviceKitCdmaDevice implementing the interfaces.
>
> Yeah, though given that we've already had a few different HAL-type
> things over the lifetime of NM, I'm a bit reluctant to use "DeviceKit"
> in the HAL/DeviceKit/udev discovered devices.
And given that most devices are discovered using these services it
should be perfectly clear not to state "DeviceKit" or anything else,
just think it as default if nothing else is stated. But I would like to
prefix Bluetooth devices for example with "NMBT".
> > I don't know.. The chart seems kind off messy. Would there actually be
> > any differences between, say, NMDeviceKitCdmaDevice and
> > NMDeviceKitGsmDevice; both just look at the device properties from
> > DeviceKit to determine the path to serial port, what else?
>
> There may be later on, though if more functionality is moved to
> ModemManager the difference between the two gets less. Still makes some
> sense to me to keep them separate for now, and they will be pretty small
> if we do our jobs correctly.
OK.
> > Oh, and btw, I added NMSerialGsmDevice and NMSerialCdmaDevice for serial
> > devices with arbitrary serial port paths. Settings would be something
> > like:
>
> Arbitrary device node entry shouldn't be part of NM anywhere. Nobody
> should have to type that in, nor does a field like that have any place
> in a UI. The only type that *might* require that is old-school
> serial-attached RS232 modems for 56k POTS dialup, and those should get
> handled through directed probing instead. NM would then pick up the
> udev capabilities of the device automatically and add it to the internal
> device list.
I have one mobile phone with RS232 connector for GRPS, but that falls
close to 56k use case. It's not a good idea to probe random devices that
are connected to COM-ports, but one solution would be to inject
necessary capabilities into DeviceKit, udev or whatever.
Back to discovering Bluetooth devices..
I'm not sure what would be the best way of doing this, but I would
suggest that we add a new settings-table "bluetooth" which can be
attached to appropriate connection hashes. For example adding
bluetooth-settings object to GSM connection hash would signal NM to
create a new Bluetooth GSM device. Same would go for Bluetooth PAN
devices.
key key type value notes
-----------------------------------------------------
name STRING bluetooth
address STRING XX:XX:XX:XX:XX:XX bluetooth address of the device
alias STRING optional, nice name for the
device. if not set device remote
name will be used
After we have BT address we can use SDP to query needed service on
remote device upon activation.
-- Antti
Attachment:
signature.asc
Description: This is a digitally signed message part