Hi,
i don't get the point why there is a difference in the configuration
file in /etc/default/bluetooth and the init script. Or the other way
around: why is hidd and hid2hci activated by default?
I don't see any sense in this.
nicholas
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tue, 2004-06-01 at 00:22 +0200, Marcel Holtmann wrote:
> Hi David,
>
> > This patch adds support to pand for writing a pidfile and cleaning up
> > the client connection on exit. I'll go play with initscripts next...
>
> I applied this patch with some small modifications. And btw you forgot
> the diff for the man page ;)
Hmm. For once I actually did that -- but evidently forgot to send it.
> I don't like --autokill and -a option. I named it --autozap and used -z
> as option.
OK.
> If you don't modify main_sopts, this won't work.
Mea culpa. I tested it with long options only, and of course it works
like that :)
--
dwmw2
On Thu, 2004-05-20 at 10:15 +0100, David Woodhouse wrote:
> In fact, I suspect that the right answer for pand is to tie it into the
> initscripts and system-config-network, so you add an interface of type
> 'PAN slave' or 'PAN master' and the network scripts handle starting and
> stopping the daemon
The advantage of doing this is that the network scripts already have
support for letting non-root users bring network devices up and down,
and the pretty GUI tools tie in with it well. It becomes a simple case
of running (or having some pretty tool run) 'ifup bnep0' and 'ifdown
bnep0'.
This patch adds support to pand for writing a pidfile and cleaning up
the client connection on exit. I'll go play with initscripts next...
Index: pand/main.c
===================================================================
RCS file: /cvsroot/bluez/utils/pand/main.c,v
retrieving revision 1.3
diff -u -r1.3 main.c
--- pand/main.c 7 May 2004 23:11:35 -0000 1.3
+++ pand/main.c 30 May 2004 16:30:25 -0000
@@ -43,6 +43,8 @@
#include <sys/socket.h>
#include <sys/poll.h>
+#include <sys/types.h>
+#include <sys/stat.h>
#include <bluetooth/bluetooth.h>
#include <bluetooth/l2cap.h>
@@ -61,6 +63,7 @@
static int use_cache;
static int encrypt;
static int master;
+static int cleanup;
static int search_duration = 10;
static struct {
@@ -70,12 +73,14 @@
} cache;
static char netdev[16] = "bnep%d";
-
+static char *pidfile = NULL;
static bdaddr_t src_addr = *BDADDR_ANY;
static int src_dev = -1;
volatile int terminate;
+static void do_kill(char *dst);
+
enum {
NONE,
SHOW,
@@ -276,9 +281,15 @@
run_devup(netdev, dst);
- if (persist)
+ if (persist) {
w4_hup(sk);
+ if (terminate && cleanup) {
+ syslog(LOG_INFO, "Disconnecting from %s.", dst);
+ do_kill(dst);
+ }
+ }
+
r = 0;
} else {
syslog(LOG_ERR, "Connect to %s failed. %s(%d)",
@@ -386,6 +397,71 @@
terminate = 1;
}
+int write_pidfile(void)
+{
+ int fd;
+ FILE *f;
+ pid_t pid;
+
+ do {
+ fd = open(pidfile, O_WRONLY|O_TRUNC|O_CREAT|O_EXCL, 0644);
+ if (fd == -1) {
+ /* Try to open the file for read. */
+ fd = open(pidfile, O_RDONLY);
+ if(fd == -1) {
+ syslog(LOG_ERR, "Could not read old pidfile: %s(%d)", strerror(errno), errno);
+ return -1;
+ }
+
+ /* We're already running; send a SIGHUP (we presume that they
+ * are calling ifup for a reason, so they probably want to
+ * rescan) and then exit cleanly and let things go on in the
+ * background. Muck with the filename so that we don't go
+ * deleting the pid file for the already-running instance.
+ */
+ f = fdopen(fd, "r");
+ if (!f) {
+ syslog(LOG_ERR, "Could not fdopen old pidfile: %s(%d)", strerror(errno), errno);
+ close(fd);
+ return -1;
+ }
+
+ pid = 0;
+ fscanf(f, "%d", &pid);
+ fclose(f);
+
+ if (pid) {
+ /* Try to kill it. */
+ if (kill(pid, SIGHUP) == -1) {
+ /* No such pid; remove the bogus pid file. */
+ syslog(LOG_INFO, "Removing stale pidfile");
+ unlink(pidfile);
+ fd = -1;
+ } else {
+ /* Got it. Don't mess with the pid file on
+ * our way out. */
+ syslog(LOG_INFO, "Signalling existing process %d and exiting\n", pid);
+ pidfile = NULL;
+ return -1;
+ }
+ }
+ }
+ } while(fd == -1);
+
+ f = fdopen(fd, "w");
+ if (!f) {
+ syslog(LOG_ERR, "Could not fdopen new pidfile: %s(%d)", strerror(errno), errno);
+ close(fd);
+ unlink(pidfile);
+ return -1;
+ }
+ fprintf(f, "%d\n", getpid());
+ fclose(f);
+ return 0;
+}
+
+
+
static struct option main_lopts[] = {
{ "help", 0, 0, 'h' },
{ "listen", 0, 0, 's' },
@@ -405,6 +481,8 @@
{ "encrypt", 0, 0, 'E' },
{ "master", 0, 0, 'M' },
{ "cache", 0, 0, 'C' },
+ { "pidfile", 1, 0, 'P' },
+ { "autokill", 0, 0, 'a' },
{ 0, 0, 0, 0 }
};
@@ -418,6 +496,7 @@
"\t--show --list -l Show active PAN connections\n"
"\t--listen -s Listen for PAN connections\n"
"\t--connect -c <bdaddr> Create PAN connection\n"
+ "\t--autokill -a Disconnect automatically on exit\n"
"\t--search -Q[duration] Search and connect\n"
"\t--kill -k <bdaddr> Kill PAN connection\n"
"\t--killall -K Kill all PAN connections\n"
@@ -430,7 +509,8 @@
"\t--master -M Become the master of a piconet\n"
"\t--nodetach -n Do not become a daemon\n"
"\t--persist -p[interval] Persist mode\n"
- "\t--cache -C[valid] Cache addresses\n";
+ "\t--cache -C[valid] Cache addresses\n"
+ "\t--pidfile -P <pidfile> Create PID file\n";
int main(int argc, char **argv)
{
@@ -519,7 +599,15 @@
else
use_cache = 2;
break;
-
+
+ case 'P':
+ pidfile = strdup(optarg);
+ break;
+
+ case 'a':
+ cleanup = 1;
+ break;
+
case 'h':
default:
printf(main_help);
@@ -588,6 +676,9 @@
}
}
+ if (pidfile && write_pidfile())
+ return -1;
+
if (dst) {
/* Disable cache invalidation */
use_cache = 0;
@@ -607,5 +698,8 @@
break;
}
+ if (pidfile)
+ unlink(pidfile);
+
return 0;
}
--
dwmw2
=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi! I recompiled your ppc rpms to i386 rpms. It is available at=20
http://kde4bl.pandayan.bayanihan.gov.ph/
Basically, these are Fedora Core 2 rpms for BlueZ.
On Thursday 20 May 2004 05:42, Marcel Holtmann wrote:
> Hi David,
>
> > It's in the bluez-utils-cups RPM. I haven't tried it as I have no
> > suitable hardware. We only have the client side implemented, don't we --
> > I can't emulate it by using another Linux/BlueZ box as the 'printer'?
>
> that is great. A "server side" is on my todo list, but I haven't written
> any line of code so far.
>
> > I note it doesn't actually try very hard to find printers :)
>
> You have to give the right URI. For example for a printer with Bluetooth
> address 00:90:02:63:e0:83 it is bluetooth://00900263E083/
>
> > > > In fact, I suspect that the right answer for pand is to tie it into
> > > > the initscripts and system-config-network, so you add an interface =
of
> > > > type 'PAN slave' or 'PAN master' and the network scripts handle
> > > > starting and stopping the daemon like they do ipppd, rather than
> > > > doing it from a SysV init script. I haven't used dund so I'm less
> > > > sure about that but it might also be the right approach there.
> > >
> > > I am not a Fedora Core user, so I can't answer this question, but in
> > > general it is up to you to decide.
> >
> > That's not really distro-specific. Well, the precise details of the
> > implementation might be -- but the idea that it's done in network
> > configuration and started like pppd on 'ifup', rather than by init like
> > a system daemon, isn't.
>
> For pand you simply start it and let the IP assignment done by the
> network hotplugging. For dund this is done by your pppd scripts. So no
> IP configuration has to be done in the init scripts, but you have to
> start the daemons somewhere. Otherwise you won't get the SDP entries and
> so nobody can find your service.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFArSuNG/HeFwSbwiYRAq5EAJ9XV26XKQsOgj8pDqlXl/Wy6BkUoQCfbSWJ
zhT0uHM37/J3GCoEVSKHRGY=3D
=3Dm9HN
=2D----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi David,
> It's in the bluez-utils-cups RPM. I haven't tried it as I have no
> suitable hardware. We only have the client side implemented, don't we --
> I can't emulate it by using another Linux/BlueZ box as the 'printer'?
that is great. A "server side" is on my todo list, but I haven't written
any line of code so far.
> I note it doesn't actually try very hard to find printers :)
You have to give the right URI. For example for a printer with Bluetooth
address 00:90:02:63:e0:83 it is bluetooth://00900263E083/
> > > In fact, I suspect that the right answer for pand is to tie it into the
> > > initscripts and system-config-network, so you add an interface of type
> > > 'PAN slave' or 'PAN master' and the network scripts handle starting and
> > > stopping the daemon like they do ipppd, rather than doing it from a SysV
> > > init script. I haven't used dund so I'm less sure about that but it
> > > might also be the right approach there.
> >
> > I am not a Fedora Core user, so I can't answer this question, but in
> > general it is up to you to decide.
>
> That's not really distro-specific. Well, the precise details of the
> implementation might be -- but the idea that it's done in network
> configuration and started like pppd on 'ifup', rather than by init like
> a system daemon, isn't.
For pand you simply start it and let the IP assignment done by the
network hotplugging. For dund this is done by your pppd scripts. So no
IP configuration has to be done in the init scripts, but you have to
start the daemons somewhere. Otherwise you won't get the SDP entries and
so nobody can find your service.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Thu, 2004-05-20 at 11:20 +0200, Marcel Holtmann wrote:
> many thanks for that.
>
> Besides these, have you checked the Bluetooth CUPS backend, which is
> also included in bluez-utils-2.7?
It's in the bluez-utils-cups RPM. I haven't tried it as I have no
suitable hardware. We only have the client side implemented, don't we --
I can't emulate it by using another Linux/BlueZ box as the 'printer'?
I note it doesn't actually try very hard to find printers :)
> > In fact, I suspect that the right answer for pand is to tie it into the
> > initscripts and system-config-network, so you add an interface of type
> > 'PAN slave' or 'PAN master' and the network scripts handle starting and
> > stopping the daemon like they do ipppd, rather than doing it from a SysV
> > init script. I haven't used dund so I'm less sure about that but it
> > might also be the right approach there.
>
> I am not a Fedora Core user, so I can't answer this question, but in
> general it is up to you to decide.
That's not really distro-specific. Well, the precise details of the
implementation might be -- but the idea that it's done in network
configuration and started like pppd on 'ifup', rather than by init like
a system daemon, isn't.
--
dwmw2
Hi David,
> OK, I've moved pand, dund and hidd into separate init scripts for
> Fedora.
>
> Updated bluez-* RPMS for FC2/ppc are in my yum repository at
> ftp://ftp.uk.linux.org/pub/people/dwmw2/fc2-mac/ (for i386 you'll want
> to rebuild them from the SRPMS which are also there). I'll probably push
> those as updates for FC2 too.
many thanks for that.
Besides these, have you checked the Bluetooth CUPS backend, which is
also included in bluez-utils-2.7?
> In fact, I suspect that the right answer for pand is to tie it into the
> initscripts and system-config-network, so you add an interface of type
> 'PAN slave' or 'PAN master' and the network scripts handle starting and
> stopping the daemon like they do ipppd, rather than doing it from a SysV
> init script. I haven't used dund so I'm less sure about that but it
> might also be the right approach there.
I am not a Fedora Core user, so I can't answer this question, but in
general it is up to you to decide.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wed, 2004-05-12 at 19:45 +0200, Marcel Holtmann wrote:
> I am thinking of a dynamic and generic config interface to every daemon,
> but this is far from any real code at the moment. So feel free to do
> what you think is the best for Fedora.
OK, I've moved pand, dund and hidd into separate init scripts for
Fedora.
Updated bluez-* RPMS for FC2/ppc are in my yum repository at
ftp://ftp.uk.linux.org/pub/people/dwmw2/fc2-mac/ (for i386 you'll want
to rebuild them from the SRPMS which are also there). I'll probably push
those as updates for FC2 too.
In fact, I suspect that the right answer for pand is to tie it into the
initscripts and system-config-network, so you add an interface of type
'PAN slave' or 'PAN master' and the network scripts handle starting and
stopping the daemon like they do ipppd, rather than doing it from a SysV
init script. I haven't used dund so I'm less sure about that but it
might also be the right approach there.
--
dwmw2
Hi David,
> It's basically only the init scripts in which my packages differ now, I
> believe. Just about everything else I had in patches is now in CVS --
> most of it a long time ago; I don't know why the swave array overflow
> slipped through the cracks.
actually I only wanna make sure that the Fedora guys are looking at the
postings on the list, because I am using a vanilla kernel and Debian ;)
> /me checks... oh, you probably want this one too...
Applied.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wed, 2004-05-12 at 19:45 +0200, Marcel Holtmann wrote:
> I am thinking of a dynamic and generic config interface to every daemon,
> but this is far from any real code at the moment. So feel free to do
> what you think is the best for Fedora. But if you change too much, then
> keep an eye on the BlueZ mailing lists for Fedora specific questions
> that I can't and actually that I won't answer.
It's basically only the init scripts in which my packages differ now, I
believe. Just about everything else I had in patches is now in CVS --
most of it a long time ago; I don't know why the swave array overflow
slipped through the cracks.
/me checks... oh, you probably want this one too...
--- bluez-utils-2.7/pcmcia/bluetooth.orig 2004-05-11 22:58:08.557536120 +0100
+++ bluez-utils-2.7/pcmcia/bluetooth 2004-05-11 22:57:03.442435120 +0100
@@ -25,7 +25,7 @@
IRQ=`setserial /dev/$DEVICE | sed -e 's/.*IRQ: //'`
setserial /dev/$DEVICE irq 0 ; setserial /dev/$DEVICE irq $IRQ
- /sbin/hciattach $DEVICE $MANFID > /tmp/pcmcia
+ /sbin/hciattach $DEVICE $MANFID
}
stop_serial() {
do_fuser -k -HUP /dev/$DEVICE > /dev/null
--
dwmw2
Hi David,
> > actually the intention of the pand and dund options in the init script
> > are for server use. You can use them for client setup, but I prefer to
> > use something extra for that. This is of course not covered.
>
> True. And there's a little bit more to be done before the point'n'drool
> user will be able to enable them like that for server mode. But still,
> it's nice to have them separate and I think that's what we'll do in
> Fedora unless you really object.
I am thinking of a dynamic and generic config interface to every daemon,
but this is far from any real code at the moment. So feel free to do
what you think is the best for Fedora. But if you change too much, then
keep an eye on the BlueZ mailing lists for Fedora specific questions
that I can't and actually that I won't answer.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi David,
> > I have no problem with that, but for the upstream package I am going to
> > keep it this way. If you aren't a developer then you start the daemons
> > at boot and kill them at shutdown. That's all.
>
> I'm not sure I agree. I'm not a developer; I'm a point'n'drool user. I
> run system-config-services and want to turn on 'pand' or 'dund' which
> are configured as clients by default so all I have to do is turn them on
> and they work...
actually the intention of the pand and dund options in the init script
are for server use. You can use them for client setup, but I prefer to
use something extra for that. This is of course not covered.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wed, 2004-05-12 at 19:29 +0200, Marcel Holtmann wrote:
> Hi David,
>
> > > I have no problem with that, but for the upstream package I am going to
> > > keep it this way. If you aren't a developer then you start the daemons
> > > at boot and kill them at shutdown. That's all.
> >
> > I'm not sure I agree. I'm not a developer; I'm a point'n'drool user. I
> > run system-config-services and want to turn on 'pand' or 'dund' which
> > are configured as clients by default so all I have to do is turn them on
> > and they work...
>
> actually the intention of the pand and dund options in the init script
> are for server use. You can use them for client setup, but I prefer to
> use something extra for that. This is of course not covered.
True. And there's a little bit more to be done before the point'n'drool
user will be able to enable them like that for server mode. But still,
it's nice to have them separate and I think that's what we'll do in
Fedora unless you really object.
--
dwmw2
On Wed, 2004-05-12 at 19:20 +0200, Marcel Holtmann wrote:
> I have no problem with that, but for the upstream package I am going to
> keep it this way. If you aren't a developer then you start the daemons
> at boot and kill them at shutdown. That's all.
I'm not sure I agree. I'm not a developer; I'm a point'n'drool user. I
run system-config-services and want to turn on 'pand' or 'dund' which
are configured as clients by default so all I have to do is turn them on
and they work...
--
dwmw2
Hi David,
> > the bluez-utils-2.7 now contains sdpd, pand, dund and hidd. So there was
> > a need for a new init script that is able to start each of these daemons
> > on bootup. I enabled hidd by default, because it didn't harm if it is
> > started and hid2hci makes also sense. Why should it not be started?
>
> For the Fedora package I've put pand, dund and hidd in separate init
> scripts. It's expected that individual services can be enabled or
> disabled with chkconfig or system-config-services, rather than by
> manually editing a separate config file.
>
> Also, I've often been glad of being able to restart pand _separately_
> from hcid and sdpd. Doesn't sdpd forget _everything_ that's registered
> when you restart it?
>
> But hid2hci does make sense, assuming of course that you're not relying
> on a Bluetooth HID device without having the Linux BT-HID support
> working yet.
I have no problem with that, but for the upstream package I am going to
keep it this way. If you aren't a developer then you start the daemons
at boot and kill them at shutdown. That's all.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wed, 2004-05-12 at 15:23 +0200, Marcel Holtmann wrote:
> Hi Nicholas,
>
> > i don't get the point why there is a difference in the configuration
> > file in /etc/default/bluetooth and the init script. Or the other way
> > around: why is hidd and hid2hci activated by default?
> > I don't see any sense in this.
>
> the bluez-utils-2.7 now contains sdpd, pand, dund and hidd. So there was
> a need for a new init script that is able to start each of these daemons
> on bootup. I enabled hidd by default, because it didn't harm if it is
> started and hid2hci makes also sense. Why should it not be started?
For the Fedora package I've put pand, dund and hidd in separate init
scripts. It's expected that individual services can be enabled or
disabled with chkconfig or system-config-services, rather than by
manually editing a separate config file.
Also, I've often been glad of being able to restart pand _separately_
from hcid and sdpd. Doesn't sdpd forget _everything_ that's registered
when you restart it?
But hid2hci does make sense, assuming of course that you're not relying
on a Bluetooth HID device without having the Linux BT-HID support
working yet.
--
dwmw2
Hi Nicholas,
> i don't get the point why there is a difference in the configuration
> file in /etc/default/bluetooth and the init script. Or the other way
> around: why is hidd and hid2hci activated by default?
> I don't see any sense in this.
the bluez-utils-2.7 now contains sdpd, pand, dund and hidd. So there was
a need for a new init script that is able to start each of these daemons
on bootup. I enabled hidd by default, because it didn't harm if it is
started and hid2hci makes also sense. Why should it not be started?
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi David,
> This patch adds support to pand for writing a pidfile and cleaning up
> the client connection on exit. I'll go play with initscripts next...
I applied this patch with some small modifications. And btw you forgot
the diff for the man page ;)
> static struct option main_lopts[] = {
> { "help", 0, 0, 'h' },
> { "listen", 0, 0, 's' },
> @@ -405,6 +481,8 @@
> { "encrypt", 0, 0, 'E' },
> { "master", 0, 0, 'M' },
> { "cache", 0, 0, 'C' },
> + { "pidfile", 1, 0, 'P' },
> + { "autokill", 0, 0, 'a' },
> { 0, 0, 0, 0 }
> };
I don't like --autokill and -a option. I named it --autozap and used -z
as option.
> + case 'P':
> + pidfile = strdup(optarg);
> + break;
> +
> + case 'a':
> + cleanup = 1;
> + break;
> +
If you don't modify main_sopts, this won't work.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel