Hi Carlo, >>> --- >>> tools/btattach.c | 10 +++++++++- >>> 1 file changed, 9 insertions(+), 1 deletion(-) >>> >>> diff --git a/tools/btattach.c b/tools/btattach.c >>> index 5adbc8d..f1f115d 100644 >>> --- a/tools/btattach.c >>> +++ b/tools/btattach.c >>> @@ -194,6 +194,7 @@ static void usage(void) >>> "\t-P, --protocol <proto> Specify protocol type\n" >>> "\t-S, --speed <baudrate> Specify which baudrate to use\n" >>> "\t-N, --noflowctl Disable flow control\n" >>> + "\t-D, --detach Open device and then fork\n" >>> "\t-h, --help Show help options\n”); >> >> And is this really a good idea. I think that I had removed all the fork calls from the standard tools. Mainly since we fail to maintain the signals and more important child signals correctly. So we quickly end up with zombies or orphaned processes. My thinking instead was to leave this to systemd to handle. > > Interesting. Any pointer how to achieve that? > The problem is that I have btattach called by a systemd unit file to > download the firmware to the bluetooth transceiver. I also have > another systemd unit that must be called strictly after btattach has > done uploading the firmware. Since btattach is hanging on the port > AFAIU there is no way I can tell exactly when it is done uploading the > firmware. That's why I was adding this detach option, to mark the unit > as 'Type=forking' and enforcing the ordering with > 'Before=next.service`. > Anything I am missing? why do you need to know when the firmware uploading has completed? What hardware is this? Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
