Re: dun profile

[Bastien Nocera <hadess@hadess.net>]

On Thu, 2009-10-15 at 11:22 -0300, Luiz Augusto von Dentz wrote:
> Hi,
> 
> On Thu, Oct 15, 2009 at 6:38 AM, Bastien Nocera <hadess@hadess.net> wrote:
> > Same questions as Stefan I'm afraid.
> >
> > In any case, I think the front-ends should be creating the port
> > themselves, so they would know which one to handle.
> >
> > See the recent (and less recent) work done in NetworkManager for DUN
> > support.
> 
> 
> Basically I want to avoid the code done in NetworkManager, simply
> because it doesn't work for anything but the one that create the port.
> So what Im proposing is that udev take care of setting the
> capabilities to the port, not the applet manually doing it, but to
> make it possible there must be something indicating that it is a port
> to dun profile channel (or spp if that matters).

It's not the applet doing it, but the daemon. And it will run
ModemManager on the device.

>  The other suggestion
> is that this port should be somehow stored so it is recreated after
> boot, but as Stefan cleverly point out this would be a bit difficult
> since some device insist in changing the channel/hide the service each
> time the profile got in use, so perhaps it is not a good idea in the
> end.
> 
> What Im still missing is how I attach the information to the port so
> that udev properly recognized and nobody has to do workarounds, store
> the return of Serial.Connect("dun") and then wait it to be announced
> by udev, than I can do it directly on bluetoothd and has to duplicate
> this code on front-ends.

That's fine if you want to hack around the device. NM/MM will add the
necessary properties to the udev device when it creates the device.