Hi
Regarding hcid initilisation, what about having the hotplug stuff
starting hcid instead of /etc/init.d/hcid?
That way hcid can be installed without using cpu/memory resources
and it will work automatically when a user inserts some Bluetooth
device.
Fredrik
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fredrik,
> > the daemons are idle if no device is attached. So who cares?
>
> System start is slower. Process list is cluttered. Memory is wasted.
> These are the main issues.
and starting from bluetooth.agent makes the agent script slower. It can
introduce race conditions.
If people plan to install Bluetooth, but don't plan to use it, we can
have a /etc/default/bluetooth option for deactivating hcid and co at
startup.
> > If they don't use Bluetooth, they don't even install it and so no
> > problem.
>
> Can I ask you: Do you use each and every single application you
> have installed on your system? :)
You won't believe it, but on my productiv systems I try to only have
applications installed that I or the system itself uses. I believe in
the way, that a minimal system is enough and if I need some other
software I install them. The Debian way with apt-get is the best I've
ever seen. I manage some system that I haven't reinstalled for over 5
years and they are as clean as I setup them.
However the bad guy is my development system, because I need hundreds of
development packages, extra tools etc. ;)
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fredrik,
> > but you expect that the user has installed the Bluetooth specific
> > software?
>
> Yes, it could be installed by default. A few megs of harddisk space
> is hardly an issue compared with having a handful of strange daemons
> (hcid, stpd etc.) always running no matter if any Bluetooth devices
> are actually available or not, is it?
the daemons are idle if no device is attached. So who cares? If they are
installed and should not be started, we can use /etc/default/bluetooth
for these kind of settings.
> > If the software is installed we start all needed parts of the
> > Bluetooth subsystem. If they don't want them they shouldn't install
> > their software.
>
> Starting these services on demand is more efficient and simpler for
> the user. Perhaps 1 % of all users will try to use the Bluetooth stuff.
If they don't use Bluetooth, they don't even install it and so no
problem. However it is _not_ efficient to start a whole subsystem with
all its daemons from a hotplug script. Everyone who likes this approch
can do it of course, but I will never accept this as default.
> > To make everything work perfect on the first use of a Bluetooth dongle
> > is not the job of the Bluetooth subsystem. If the USB or PCMCIA subsytem
> > detects a Bluetooth device it has to install, start or run whatever
> > other action is needed to make it work.
>
> This would require that hcid is compatible with that approach. That's
> the issue here. :)
No. This requires that the USB and PCMCIA subsystem knows what devices
are Bluetooth devices. If not installed they have to install the BlueZ
packages that are needed and then they have to run the init script.
> > If hcid is not running, because no device is attached. How would you
> > manage you pairings through D-Bus for example? For some stuff an
> > attached device is not needed.
>
> The hotplug may not be the only way to start hcid. Other services
> may require it to start too, of course.
Two places where we have to start a daemon? Too complex. Start it at
init.
> > If you think the long way then after hcid comes sdpd. This daemon must
> > be started first, before any PAN service can be started.
>
> This kind of dependency needs to be tracked too.
I don't wanna track this down. Start hcid and sdpd and then everything
else you want. Starting them from init is the best way.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
m?n 2004-02-09 klockan 13.50 skrev Marcel Holtmann:
> the daemons are idle if no device is attached. So who cares?
System start is slower. Process list is cluttered. Memory is wasted.
These are the main issues.
> If they don't use Bluetooth, they don't even install it and so no
> problem.
Can I ask you: Do you use each and every single application you
have installed on your system? :)
> Two places where we have to start a daemon? Too complex. Start it at
> init.
If the hotplug scripts somehow could talk to init, that'll work I
suppose?
Fredrik
Marcel,
m?n 2004-02-09 klockan 12.20 skrev Marcel Holtmann:
> but you expect that the user has installed the Bluetooth specific
> software?
Yes, it could be installed by default. A few megs of harddisk space
is hardly an issue compared with having a handful of strange daemons
(hcid, stpd etc.) always running no matter if any Bluetooth devices
are actually available or not, is it?
> If the software is installed we start all needed parts of the
> Bluetooth subsystem. If they don't want them they shouldn't install
> their software.
Starting these services on demand is more efficient and simpler for
the user. Perhaps 1 % of all users will try to use the Bluetooth stuff.
> To make everything work perfect on the first use of a Bluetooth dongle
> is not the job of the Bluetooth subsystem. If the USB or PCMCIA subsytem
> detects a Bluetooth device it has to install, start or run whatever
> other action is needed to make it work.
This would require that hcid is compatible with that approach. That's
the issue here. :)
> If hcid is not running, because no device is attached. How would you
> manage you pairings through D-Bus for example? For some stuff an
> attached device is not needed.
The hotplug may not be the only way to start hcid. Other services
may require it to start too, of course.
> If you think the long way then after hcid comes sdpd. This daemon must
> be started first, before any PAN service can be started.
This kind of dependency needs to be tracked too.
Fredrik
Hi Fredrik,
> > no. The bluetooth.agent is only for device specific configuration and
> > not for starting a deamon. However hcid watches all interfaces and
> > bluetooth.agent would be called for every device.
>
> Having hcid actively running on a system that never will use a
> Bluetooth device is waste of resources. But when a user inserts
> a Bluetooth device, it would be excellent to have it all work
> automtically. What do you suggest then?
but you expect that the user has installed the Bluetooth specific
software? If the software is installed we start all needed parts of the
Bluetooth subsystem. If they don't want them they shouldn't install
their software.
To make everything work perfect on the first use of a Bluetooth dongle
is not the job of the Bluetooth subsystem. If the USB or PCMCIA subsytem
detects a Bluetooth device it has to install, start or run whatever
other action is needed to make it work.
> > Multiple running hcid's will mess up the security manager.
>
> Yes, but only one hcid instance would run. The hotplug script and/or
> hcid can check this.
If hcid is not running, because no device is attached. How would you
manage you pairings through D-Bus for example? For some stuff an
attached device is not needed.
If you think the long way then after hcid comes sdpd. This daemon must
be started first, before any PAN service can be started. Starting all
daemons from bluetooth.agent is stupid, because none of them actually
are bound to a specific device. And people also reported that starting
daemons from bluetooth.agent causes troubles.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
m?n 2004-02-09 klockan 11.47 skrev Marcel Holtmann:
> no. The bluetooth.agent is only for device specific configuration and
> not for starting a deamon. However hcid watches all interfaces and
> bluetooth.agent would be called for every device.
Having hcid actively running on a system that never will use a
Bluetooth device is waste of resources. But when a user inserts
a Bluetooth device, it would be excellent to have it all work
automtically. What do you suggest then?
> Multiple running hcid's will mess up the security manager.
Yes, but only one hcid instance would run. The hotplug script and/or
hcid can check this.
Fredrik
Hi Fredrik,
> Regarding hcid initilisation, what about having the hotplug stuff
> starting hcid instead of /etc/init.d/hcid?
>
> That way hcid can be installed without using cpu/memory resources
> and it will work automatically when a user inserts some Bluetooth
> device.
no. The bluetooth.agent is only for device specific configuration and
not for starting a deamon. However hcid watches all interfaces and
bluetooth.agent would be called for every device. Multiple running
hcid's will mess up the security manager.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel