Hi Marcel,
This is a patch I wrote a couple of months back, and I would
like to submit it for inclusion in the BlueZ stack. The reason I think
we should include that is that the patch has minimal footprint and
offer a feature unavailable by other means...
The idea is that this patch add an event that is trigger when
a connection is likely to fail, but before the connection get
disconnected. This is similar to the TxDrop iwevent implemented for
802.11 (in Wireless Extensions).
In many cases, you don't want to use LinkSupervisionTimeout,
because it disconnect the connection before you have time to take
corrective action (i.e. game over).
The main use is for Ad-Hoc routing protocol (mesh) such as
AODV. In the litterature, this is called a "link trigger". I can give
you real world example of people using the TxDrop iwevent in AODV
implementations.
Another example would be to use this event to generate a
warning to the user that his connection is about to drop. Because
LinkSupervisionTimeout is so large, most users would be able to use
this warning to get back into range or away from the interferer
without loosing the connection.
I could go at lenght on why this is useful and why this is the
way to implement it, but I don't want to waste your time.
Patch has been tested in kernel from 2.6.1 to 2.6.8. I also
have a patch for 2.4.X. Please apply...
Regards,
Jean
---------------------------------------------------------
diff -u -p linux/net/bluetooth/Kconfig.m1 linux/net/bluetooth/Kconfig
--- linux/net/bluetooth/Kconfig.m1 Tue Aug 3 11:00:19 2004
+++ linux/net/bluetooth/Kconfig Tue Aug 3 11:05:54 2004
@@ -60,4 +60,14 @@ source "net/bluetooth/cmtp/Kconfig"
source "net/bluetooth/hidp/Kconfig"
source "drivers/bluetooth/Kconfig"
+
+config BT_WARNDELAY
+ bool "ACL delay warning"
+ depends on BT
+ help
+ Trigger a HCI event is ACL transmit did not complete in a certain
+ time. This is a "link trigger" used to optimise most Ad-Hoc
+ routing protocols such as AODV, and can be used when you need to
+ know very quickly if a L2CAP connection is going bad...
+ Just say N if you don't understand the above.
diff -u -p linux/include/net/bluetooth/hci.m1.h linux/include/net/bluetooth/hci.h
--- linux/include/net/bluetooth/hci.m1.h Tue Aug 3 11:00:42 2004
+++ linux/include/net/bluetooth/hci.h Tue Aug 3 11:02:08 2004
@@ -92,6 +92,7 @@ enum {
#define HCISETACLMTU _IOW('H', 227, int)
#define HCISETSCOMTU _IOW('H', 228, int)
#define HCISETRAWVND _IOW('H', 229, int)
+#define HCISETWARNDELAY _IOW('H', 230, int)
#define HCIINQUIRY _IOR('H', 240, int)
@@ -563,6 +564,12 @@ struct hci_ev_si_security {
__u16 proto;
__u16 subproto;
__u8 incoming;
+} __attribute__ ((packed));
+
+#define HCI_EV_SI_WARNDELAY 0x03
+struct hci_ev_si_warndelay {
+ __u16 handle;
+ __u32 delay; /* ms */
} __attribute__ ((packed));
/* ---- HCI Packet structures ---- */
diff -u -p linux/include/net/bluetooth/hci_core.m1.h linux/include/net/bluetooth/hci_core.h
--- linux/include/net/bluetooth/hci_core.m1.h Tue Aug 3 11:00:53 2004
+++ linux/include/net/bluetooth/hci_core.h Tue Aug 3 11:02:08 2004
@@ -72,6 +72,9 @@ struct hci_dev {
__u16 pkt_type;
__u16 link_policy;
__u16 link_mode;
+#ifdef CONFIG_BT_WARNDELAY
+ unsigned long warn_delay;
+#endif /* CONFIG_BT_WARNDELAY */
unsigned long quirks;
@@ -145,6 +148,10 @@ struct hci_conn {
unsigned long pend;
unsigned int sent;
+#ifdef CONFIG_BT_WARNDELAY
+ unsigned long last_ack;
+ struct timer_list warndelay_timer;
+#endif /* CONFIG_BT_WARNDELAY */
struct sk_buff_head data_q;
diff -u -p linux/net/bluetooth/hci_conn.m1.c linux/net/bluetooth/hci_conn.c
--- linux/net/bluetooth/hci_conn.m1.c Tue Aug 3 11:01:12 2004
+++ linux/net/bluetooth/hci_conn.c Tue Aug 3 11:02:08 2004
@@ -140,6 +140,35 @@ static void hci_conn_init_timer(struct h
conn->timer.data = (unsigned long)conn;
}
+#ifdef CONFIG_BT_WARNDELAY
+static void hci_warndelay_timeout(unsigned long arg)
+{
+ struct hci_conn *conn = (void *)arg;
+ struct hci_dev *hdev = conn->hdev;
+ struct hci_ev_si_warndelay ev;
+
+ /* We didn't receive the Tx ack in the expected time, generate
+ * an event to user space. Jean II */
+
+ BT_DBG("conn %p state %d", conn, conn->state);
+
+ hci_dev_lock(hdev);
+
+ /* Send event to HCI sockets */
+ ev.handle = conn->handle;
+ ev.delay = (jiffies - conn->last_ack) * 1000 / HZ;
+ hci_si_event(NULL, HCI_EV_SI_WARNDELAY,
+ sizeof(ev), &ev);
+
+ /* Re-arm timer */
+ mod_timer(&(conn->warndelay_timer),
+ jiffies + hdev->warn_delay);
+
+ hci_dev_unlock(hdev);
+ return;
+}
+#endif /* CONFIG_BT_WARNDELAY */
+
struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst)
{
struct hci_conn *conn;
@@ -157,6 +186,12 @@ struct hci_conn *hci_conn_add(struct hci
skb_queue_head_init(&conn->data_q);
hci_conn_init_timer(conn);
+#ifdef CONFIG_BT_WARNDELAY
+ /* This timer generates event on ACL stalls. Jean II */
+ init_timer(&conn->warndelay_timer);
+ conn->warndelay_timer.function = hci_warndelay_timeout;
+ conn->warndelay_timer.data = (unsigned long) conn;
+#endif /* CONFIG_BT_WARNDELAY */
atomic_set(&conn->refcnt, 0);
@@ -179,6 +214,10 @@ int hci_conn_del(struct hci_conn *conn)
BT_DBG("%s conn %p handle %d", hdev->name, conn, conn->handle);
hci_conn_del_timer(conn);
+#ifdef CONFIG_BT_WARNDELAY
+ if(timer_pending(&(conn->warndelay_timer)))
+ del_timer(&(conn->warndelay_timer));
+#endif /* CONFIG_BT_WARNDELAY */
if (conn->type == SCO_LINK) {
struct hci_conn *acl = conn->link;
diff -u -p linux/net/bluetooth/hci_core.m1.c linux/net/bluetooth/hci_core.c
--- linux/net/bluetooth/hci_core.m1.c Tue Aug 3 11:01:25 2004
+++ linux/net/bluetooth/hci_core.c Tue Aug 3 11:02:08 2004
@@ -677,6 +677,17 @@ int hci_dev_cmd(unsigned int cmd, void _
hdev->sco_pkts = *((__u16 *)&dr.dev_opt + 0);
break;
+#ifdef CONFIG_BT_WARNDELAY
+ case HCISETWARNDELAY:
+ /* This setting is "per interface". You may want to do
+ * it "per connection", but that's much more messy.
+ * To disable, set 0
+ * The value is in ms, so convert it to jiffies.
+ * Jean II */
+ hdev->warn_delay = (unsigned long) dr.dev_opt * HZ / 1000;
+ break;
+#endif /* CONFIG_BT_WARNDELAY */
+
default:
err = -EINVAL;
break;
@@ -816,6 +827,9 @@ int hci_register_dev(struct hci_dev *hde
hdev->flags = 0;
hdev->pkt_type = (HCI_DM1 | HCI_DH1 | HCI_HV1);
hdev->link_mode = (HCI_LM_ACCEPT);
+#ifdef CONFIG_BT_WARNDELAY
+ hdev->warn_delay = 0; /* Disabled */
+#endif /* CONFIG_BT_WARNDELAY */
tasklet_init(&hdev->cmd_task, hci_cmd_task,(unsigned long) hdev);
tasklet_init(&hdev->rx_task, hci_rx_task, (unsigned long) hdev);
@@ -1166,6 +1180,15 @@ static inline void hci_sched_acl(struct
BT_DBG("skb %p len %d", skb, skb->len);
hci_send_frame(skb);
hdev->acl_last_tx = jiffies;
+
+#ifdef CONFIG_BT_WARNDELAY
+ /* Start the warndelay timer if not pending */
+ if ((conn->sent == 0) && (hdev->warn_delay != 0)) {
+ conn->last_ack = jiffies;
+ conn->warndelay_timer.expires = jiffies + hdev->warn_delay;
+ add_timer(&(conn->warndelay_timer));
+ }
+#endif /* CONFIG_BT_WARNDELAY */
hdev->acl_cnt--;
conn->sent++;
diff -u -p linux/net/bluetooth/hci_event.m1.c linux/net/bluetooth/hci_event.c
--- linux/net/bluetooth/hci_event.m1.c Tue Aug 3 11:01:36 2004
+++ linux/net/bluetooth/hci_event.c Tue Aug 3 11:02:08 2004
@@ -679,6 +679,21 @@ static inline void hci_num_comp_pkts_evt
if (conn) {
conn->sent -= count;
+#ifdef CONFIG_BT_WARNDELAY
+ if ((count) && (conn->type == ACL_LINK) &&
+ (hdev->warn_delay != 0)) {
+ if (conn->sent == 0) {
+ /* No pending packets, cancel */
+ del_timer(&(conn->warndelay_timer));
+ } else {
+ /* Pending packets, re-arm */
+ conn->last_ack = jiffies;
+ mod_timer(&(conn->warndelay_timer),
+ jiffies + hdev->warn_delay);
+ }
+ }
+#endif /* CONFIG_BT_WARNDELAY */
+
if (conn->type == SCO_LINK) {
if ((hdev->sco_cnt += count) > hdev->sco_pkts)
hdev->sco_cnt = hdev->sco_pkts;
diff -u -p linux/net/bluetooth/hci_sock.m1.c linux/net/bluetooth/hci_sock.c
--- linux/net/bluetooth/hci_sock.m1.c Tue Aug 3 11:01:48 2004
+++ linux/net/bluetooth/hci_sock.c Tue Aug 3 11:02:08 2004
@@ -241,6 +241,7 @@ static int hci_sock_ioctl(struct socket
case HCISETLINKMODE:
case HCISETACLMTU:
case HCISETSCOMTU:
+ case HCISETWARNDELAY:
if (!capable(CAP_NET_ADMIN))
return -EACCES;
return hci_dev_cmd(cmd, argp);
On Wed, Aug 11, 2004 at 12:53:23AM +0200, Marcel Holtmann wrote:
> Hi Jean,
>
> you are right, but there are pros and cons on both sides and I like to
> find the best solution. However I never looked at RtNetlink before. I
> think that I should educate myself a little bit more.
Netlink is a generic socket between the kernel and user space,
RtNetlink is a API using Netlink to manipulate IP routes and a few
other stuff.
Start with the iproute package, which is an user interface to
RtNetlink (the command part). Then, look at iwevent, that make use of
various RtNetlink events.
Note that you can't migrate the HCI events to RtNetlink,
because RtNetlink expect a real netdev. You could migrate to Netlink,
defining you own API over Netlink, but I don't see what would be the
gain.
> > The bug is obvious, you forgot that in 2.4.X the list doesn't
> > point to struct sock but to struct bluez_pinfo. Compare your patch to
> > the version below.
>
> What a stupid mistake. I must been blind at that time :(
It happens to all of us ;-) I'm glad I started with my own
backport and had my own separate patch, because otherwise I would not
have find this bug...
> Regards
>
> Marcel
Have fun...
Jean
Hi Jean,
> > If the HCI connections themself are fully integrated into the driver and
> > device model an event through hotplug would be the best. Comments?
>
> I personally don't like hotplug for this application. Hotplug
> force the event to go through a bunch of scripts, which is good for
> simple config and daemon-less stuff, but bad for daemons.
> Let say you have a big daemon monitoring a bunch of stuff and
> keeping track of state. Examples are pand, waproamd, MobileIP... With
> hotplug you have to write a script that somehow forward the event to
> the daemon. As events are usually passed via Unix sockets, shared
> memory or something similar, the scripts need to call a little program
> generating the event.
> Therefore you have :
> hotplug event ->
> -> my shell script
> -> my tiny program
> -> Unix socket or shared memory
> -> My daemon
> For each event, you need to create two processes (shell script
> and tiny program) than need to be paged from disk. Yuck...
> If you look at waproamd, it uses exclusively the RtNetlink
> events, even though the equivalent events exist in Hotplug.
you are right, but there are pros and cons on both sides and I like to
find the best solution. However I never looked at RtNetlink before. I
think that I should educate myself a little bit more.
> > > > I sent the full patch for inclusion, but it came out that one part
> > > > causes troubles and so I removed this part. I didn't found the time for
> > > > a further investigation.
> > >
> > > That's what I said : I'm going to test it properly. If you
> > > could remember the issue, that would help.
> >
> > I searched the email exchange between Michal and me from the mailing
> > list archives for you. Check out this thread:
> >
> > http://thread.gmane.org/gmane.linux.bluez.user/2672
>
> The bug is obvious, you forgot that in 2.4.X the list doesn't
> point to struct sock but to struct bluez_pinfo. Compare your patch to
> the version below.
What a stupid mistake. I must been blind at that time :(
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tue, Aug 10, 2004 at 10:13:19AM +0200, Marcel Holtmann wrote:
> Hi Jean,
>
> > > this is a good point and I do think that this patch is a nice additional
> > > feature for BlueZ, but I am not fully comfortable with it in its current
> > > shape. Actually some time ago I thought about removing the support for
> > > stack internal events.
> >
> > In my stuff, I use internal events to know when hci interfaces
> > go up and down and when they appear and disappear. As far as I know,
> > those events are not available by any other means. They are not
> > available through RtNetlink because hci interfaces are not real netdev
> > interfaces.
>
> these events should be available via hotplug and the bluetooth.agent and
> because of this I was thinking about removing the stack internal stuff.
>
> If the HCI connections themself are fully integrated into the driver and
> device model an event through hotplug would be the best. Comments?
I personally don't like hotplug for this application. Hotplug
force the event to go through a bunch of scripts, which is good for
simple config and daemon-less stuff, but bad for daemons.
Let say you have a big daemon monitoring a bunch of stuff and
keeping track of state. Examples are pand, waproamd, MobileIP... With
hotplug you have to write a script that somehow forward the event to
the daemon. As events are usually passed via Unix sockets, shared
memory or something similar, the scripts need to call a little program
generating the event.
Therefore you have :
hotplug event ->
-> my shell script
-> my tiny program
-> Unix socket or shared memory
-> My daemon
For each event, you need to create two processes (shell script
and tiny program) than need to be paged from disk. Yuck...
If you look at waproamd, it uses exclusively the RtNetlink
events, even though the equivalent events exist in Hotplug.
> > > I sent the full patch for inclusion, but it came out that one part
> > > causes troubles and so I removed this part. I didn't found the time for
> > > a further investigation.
> >
> > That's what I said : I'm going to test it properly. If you
> > could remember the issue, that would help.
>
> I searched the email exchange between Michal and me from the mailing
> list archives for you. Check out this thread:
>
> http://thread.gmane.org/gmane.linux.bluez.user/2672
The bug is obvious, you forgot that in 2.4.X the list doesn't
point to struct sock but to struct bluez_pinfo. Compare your patch to
the version below.
Patch has been tested to my satisfaction. If Michal Semler
want to test it, that woud be even better.
> Regards
>
> Marcel
Have fun...
Jean
--------------------------------------------------
diff -u -p linux/net/bluetooth/af_bluetooth.j2.c linux/net/bluetooth/af_bluetooth.c
--- linux/net/bluetooth/af_bluetooth.j2.c Fri Aug 6 18:38:53 2004
+++ linux/net/bluetooth/af_bluetooth.c Fri Aug 6 18:48:28 2004
@@ -218,6 +218,22 @@ int bluez_sock_recvmsg(struct socket *so
return err ? : copied;
}
+static inline unsigned int bluez_accept_poll(struct sock *parent)
+{
+ struct list_head *p, *n;
+ struct bluez_pinfo *pi;
+ struct sock *sk;
+
+ list_for_each_safe(p, n, &bluez_pi(parent)->accept_q) {
+ pi = list_entry(p, struct bluez_pinfo, accept_q);
+ sk = bluez_sk(pi);
+ if (sk->state == BT_CONNECTED)
+ return POLLIN | POLLRDNORM;
+ }
+
+ return 0;
+}
+
unsigned int bluez_sock_poll(struct file * file, struct socket *sock, poll_table *wait)
{
struct sock *sk = sock->sk;
@@ -226,6 +242,9 @@ unsigned int bluez_sock_poll(struct file
BT_DBG("sock %p, sk %p", sock, sk);
poll_wait(file, sk->sleep, wait);
+
+ if (sk->state == BT_LISTEN)
+ return bluez_accept_poll(sk);
if (sk->err || !skb_queue_empty(&sk->error_queue))
mask |= POLLERR;
Hi Jean,
> > this is a good point and I do think that this patch is a nice additional
> > feature for BlueZ, but I am not fully comfortable with it in its current
> > shape. Actually some time ago I thought about removing the support for
> > stack internal events.
>
> In my stuff, I use internal events to know when hci interfaces
> go up and down and when they appear and disappear. As far as I know,
> those events are not available by any other means. They are not
> available through RtNetlink because hci interfaces are not real netdev
> interfaces.
these events should be available via hotplug and the bluetooth.agent and
because of this I was thinking about removing the stack internal stuff.
If the HCI connections themself are fully integrated into the driver and
device model an event through hotplug would be the best. Comments?
> > I sent the full patch for inclusion, but it came out that one part
> > causes troubles and so I removed this part. I didn't found the time for
> > a further investigation.
>
> That's what I said : I'm going to test it properly. If you
> could remember the issue, that would help.
I searched the email exchange between Michal and me from the mailing
list archives for you. Check out this thread:
http://thread.gmane.org/gmane.linux.bluez.user/2672
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Mon, Aug 09, 2004 at 09:08:36PM +0200, Marcel Holtmann wrote:
> Hi Jean,
>
> > > no problem, I got the point. However I am not sure about applying your
> > > patch. I don't like the way the event is propagated. It is a connection
> > > related event and so I like to send it to the sockets that are using
> > > that ACL connection. Or at least I should introduce the per device stack
> > > internal events.
> >
> > The typical application is to monitor a BNEP connection (AODV
> > deals with TCP/IP traffic). The L2CAP socket for the BNEP traffic is
> > owned by the PAN deamon. However, you may want to feed the event
> > directly to AODV without having to modify the PAN daemon and having to
> > relay events.
>
> this is a good point and I do think that this patch is a nice additional
> feature for BlueZ, but I am not fully comfortable with it in its current
> shape. Actually some time ago I thought about removing the support for
> stack internal events.
In my stuff, I use internal events to know when hci interfaces
go up and down and when they appear and disappear. As far as I know,
those events are not available by any other means. They are not
available through RtNetlink because hci interfaces are not real netdev
interfaces.
I personally prefer event driver APIs rather than blocking
APIs, I find it much more flexible. And it fits with the raw HCI API.
> > Note that the patch for the poll/listen bug was only partially
> > applied to 2.4.X, I have a patch for it, I still need to test it.
>
> I sent the full patch for inclusion, but it came out that one part
> causes troubles and so I removed this part. I didn't found the time for
> a further investigation.
That's what I said : I'm going to test it properly. If you
could remember the issue, that would help.
> Regards
>
> Marcel
Jean
Hi Jean,
> > no problem, I got the point. However I am not sure about applying your
> > patch. I don't like the way the event is propagated. It is a connection
> > related event and so I like to send it to the sockets that are using
> > that ACL connection. Or at least I should introduce the per device stack
> > internal events.
>
> The typical application is to monitor a BNEP connection (AODV
> deals with TCP/IP traffic). The L2CAP socket for the BNEP traffic is
> owned by the PAN deamon. However, you may want to feed the event
> directly to AODV without having to modify the PAN daemon and having to
> relay events.
this is a good point and I do think that this patch is a nice additional
feature for BlueZ, but I am not fully comfortable with it in its current
shape. Actually some time ago I thought about removing the support for
stack internal events.
Any additional comments are welcome.
> > Another question is, do we need a compile option for it? Is there any
> > disadvantage to compile it always and disable by default?
>
> For a (still) experimental feature, it make sense to keep it
> encapsualted. It's easier to remove #define than to add it. Your call.
When I include it in my -mh patch I will always enable it, but keep the
ifdefs.
> Note that the patch for the poll/listen bug was only partially
> applied to 2.4.X, I have a patch for it, I still need to test it.
I sent the full patch for inclusion, but it came out that one part
causes troubles and so I removed this part. I didn't found the time for
a further investigation.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Sun, Aug 08, 2004 at 04:49:08PM +0200, Marcel Holtmann wrote:
> Hi Jean,
>
> no problem, I got the point. However I am not sure about applying your
> patch. I don't like the way the event is propagated. It is a connection
> related event and so I like to send it to the sockets that are using
> that ACL connection. Or at least I should introduce the per device stack
> internal events.
The typical application is to monitor a BNEP connection (AODV
deals with TCP/IP traffic). The L2CAP socket for the BNEP traffic is
owned by the PAN deamon. However, you may want to feed the event
directly to AODV without having to modify the PAN daemon and having to
relay events.
> Another question is, do we need a compile option for it? Is there any
> disadvantage to compile it always and disable by default?
For a (still) experimental feature, it make sense to keep it
encapsualted. It's easier to remove #define than to add it. Your call.
> > Patch has been tested in kernel from 2.6.1 to 2.6.8. I also
> > have a patch for 2.4.X. Please apply...
>
> I would include it into my next -mh patch for testing, but the 2.4
> series should be closed for new features.
I know, that's why I kept it for myself.
Note that the patch for the poll/listen bug was only partially
applied to 2.4.X, I have a patch for it, I still need to test it.
> Regards
>
> Marcel
Have fun...
Jean
Hi Jean,
> This is a patch I wrote a couple of months back, and I would
> like to submit it for inclusion in the BlueZ stack. The reason I think
> we should include that is that the patch has minimal footprint and
> offer a feature unavailable by other means...
>
> The idea is that this patch add an event that is trigger when
> a connection is likely to fail, but before the connection get
> disconnected. This is similar to the TxDrop iwevent implemented for
> 802.11 (in Wireless Extensions).
> In many cases, you don't want to use LinkSupervisionTimeout,
> because it disconnect the connection before you have time to take
> corrective action (i.e. game over).
> The main use is for Ad-Hoc routing protocol (mesh) such as
> AODV. In the litterature, this is called a "link trigger". I can give
> you real world example of people using the TxDrop iwevent in AODV
> implementations.
> Another example would be to use this event to generate a
> warning to the user that his connection is about to drop. Because
> LinkSupervisionTimeout is so large, most users would be able to use
> this warning to get back into range or away from the interferer
> without loosing the connection.
> I could go at lenght on why this is useful and why this is the
> way to implement it, but I don't want to waste your time.
no problem, I got the point. However I am not sure about applying your
patch. I don't like the way the event is propagated. It is a connection
related event and so I like to send it to the sockets that are using
that ACL connection. Or at least I should introduce the per device stack
internal events.
Another question is, do we need a compile option for it? Is there any
disadvantage to compile it always and disable by default?
> Patch has been tested in kernel from 2.6.1 to 2.6.8. I also
> have a patch for 2.4.X. Please apply...
I would include it into my next -mh patch for testing, but the 2.4
series should be closed for new features.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. http://www.ostg.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel