Re: [PATCH 1/1] net: mark net_proto_ops as const

On Fri, Oct 02, 2009 at 04:25:21PM -0700, Stephen Hemminger wrote:
> --- a/net/can/af_can.c
> +++ b/net/can/af_can.c
>  <at>  <at>  -842,7 +842,7  <at>  <at>  static struct packet_type can_packet __r
>  	.func = can_rcv,
>  };
>  
> -static struct net_proto_family can_family_ops __read_mostly = {
> +static const struct net_proto_family can_family_ops __read_mostly = {
						       ^^^^^^^^^^^^^
>  	.family = PF_CAN,
>  	.create = can_create,
>  	.owner  = THIS_MODULE,

ACK, except this chunk: const already means read-only.

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf

[PATCH 1/1] net: mark net_proto_ops as const

All users of structure net_proto_ops should be declared const.

---
 drivers/isdn/mISDN/socket.c       |    3 +--
 drivers/net/pppox.c               |    2 +-
 include/net/bluetooth/bluetooth.h |    2 +-
 net/appletalk/ddp.c               |    2 +-
 net/atm/pvc.c                     |    2 +-
 net/atm/svc.c                     |    2 +-
 net/ax25/af_ax25.c                |    2 +-
 net/bluetooth/af_bluetooth.c      |    4 ++--
 net/bluetooth/bnep/sock.c         |    2 +-
 net/bluetooth/cmtp/sock.c         |    2 +-
 net/bluetooth/hci_sock.c          |    2 +-
 net/bluetooth/hidp/sock.c         |    2 +-
 net/bluetooth/l2cap.c             |    2 +-
 net/bluetooth/rfcomm/sock.c       |    2 +-
 net/bluetooth/sco.c               |    2 +-
 net/can/af_can.c                  |    2 +-
 net/decnet/af_decnet.c            |    2 +-
 net/econet/af_econet.c            |    2 +-
 net/ieee802154/af_ieee802154.c    |    2 +-
 net/ipv4/af_inet.c                |    2 +-
 net/ipv6/af_inet6.c               |    2 +-
 net/ipx/af_ipx.c                  |    2 +-
 net/irda/af_irda.c                |    2 +-
 net/iucv/af_iucv.c                |    2 +-
 net/key/af_key.c                  |    2 +-
 net/llc/af_llc.c                  |    2 +-
 net/netlink/af_netlink.c          |    2 +-

Re: About Device and Driver and Ping behaviour

Hi,

Ok ! That's really not a "definitive/perennial " hack but i did verify 
that IPV4/UDP/ICMP packets could be exchange with my 
WPC/Contiki/SicsLowPan (reduced to IPV4 for now) Network sensors.
Ijust did some sligth modifications in "dev.c" (6 lines added only) and 
a bit of "wpan1" interface configuration (give inet parameters) and my 
sensors are now reachable from internet with a simple UDP socket and 
some NAT configurations on my LAN and my Linux !

I really get more and more found of your project !
Hope to have news about it soon.

Pierre-emmanuel

Pierre-emmanuel Goudet a écrit :
> Hi,
>
> To go on testing what is possible with the WPAN/WPC serial interface, 
> I'd like to send an IPV4 simple ICMP message (Ping) across the 
> MWPAN1/serial interface, with a simple command:
>
> # ping -I wpan1 "IpDest"
>
> I can "sniff" the frame sent on my media, and it seems quite OK.
> In fact all the ICMP part of the frame is OK, But the ICMP packet is 
> encapsulated into 802.15.4 'BEACON' type packet  (Type  00), in fact i 
> think header is not initialized ?
> I 'd like to have it encapsulated in a 802.15.4 / 'DATA type' / 
> broadcasted (short dest 0xFFFF) packet.

Re: About Device and Driver and Ping behaviour

Dear Pierre-emmanuel,

I'm glad you are having progress! Unfortunately I didn't have much
time for this project lately and I'm really glad that you achieved
such results!

Kind regards,
Maxim

On Fri, Oct 9, 2009 at 3:38 PM, Pierre-emmanuel Goudet
<pe.goudet@...> wrote:
> Hi,
>
> Ok ! That's really not a "definitive/perennial " hack but i did verify that
> IPV4/UDP/ICMP packets could be exchange with my WPC/Contiki/SicsLowPan
> (reduced to IPV4 for now) Network sensors.
> Ijust did some sligth modifications in "dev.c" (6 lines added only) and a
> bit of "wpan1" interface configuration (give inet parameters) and my sensors
> are now reachable from internet with a simple UDP socket and some NAT
> configurations on my LAN and my Linux !
>
> I really get more and more found of your project !
> Hope to have news about it soon.
>
> Pierre-emmanuel
>
> Pierre-emmanuel Goudet a écrit :
>>
>> Hi,
>>

serial performance

I've been trying to see if I can set up a 802.15.4 network and have
other 802.15.4 compliant devices join the network.  I however am
noticing that when the other device expects to get an ACK, it only
waits 50ms before retransmitting.  Now I don't have the ACK working
yet, but in my system, due to scheduling and so on with the serial
port data, I don't even start processing the incoming message until
30-40 ms after it has arrived.  By the time the CCA, TX, and DATA
messages have been sent I'm up to about 120ms.  At this rate, my
system gets tied up processing the message and the retransmits so it
won't be able to send out an ACK before the other side gives up
entirely.

Does this sound right compared to what others are seeing on PCs?

I was thinking of trying to eliminate some of the waiting between PHY
messages by combining them into one message so it only has to be acked
once.  This would at least eliminate the 20-30ms of waiting for the
response to each message.

Any thoughts?

Andrew

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

Re: serial performance

Andrew Webster wrote:

> I've been trying to see if I can set up a 802.15.4 network and have
> other 802.15.4 compliant devices join the network.  I however am
> noticing that when the other device expects to get an ACK, it only waits
> 50ms before retransmitting.  Now I don't have the ACK working yet, but
> in my system, due to scheduling and so on with the serial port data, I
> don't even start processing the incoming message until 30-40 ms after it
> has arrived.  By the time the CCA, TX, and DATA messages have been sent
> I'm up to about 120ms.  At this rate, my system gets tied up processing
> the message and the retransmits so it won't be able to send out an ACK
> before the other side gives up entirely.
> 
> Does this sound right compared to what others are seeing on PCs?

Yes. That's why I'd dropped all software ACK generation and moved CCA calls
to tx driver callback: they should be done either by HW or by firmware running
on the dongle. Otherwise we won't get timing accurately.

> I was thinking of trying to eliminate some of the waiting between PHY
> messages by combining them into one message so it only has to be acked
> once.  This would at least eliminate the 20-30ms of waiting for the
> response to each message.

Moreover It seems that to support necessary timing the packet should be
received in stream mode (to be analyzed in the same time, as it's received).

I have an implementation of working STREAM mode of MC13192, however no
work to completely debug things was done.

Re: serial performance

Hi Dmitry, all,

As you said you will work in serial ZB protocol evolutions to allow 
better management of hardware capabilities of transceiver,
would it be possible to add these kind of 'ops' in serial driver (hence 
protocol) and link them to specific 'ops' in the corresponding kernel 
device:

==> For global ACK capabilities (as you discussed with Andrew)
.set_auto_ack_(on/off)
.set_auto_crc_(on/off)
.set_mac_address (u64)
.set_short_address (u16)
.set_panid (u16)

==> For 802.15.4 CSMA/CA tx capabilities:
.set_auto_retry (on/off)
.set_nb_csma_retries(u8)
.set_nb_retries(u8)
.set_min_backoff_exponent (u8)

Maybe all this and existing '.set' would also necessitate a 'get' 
capability also ?

I think these kind of ops are quite common to many hardware transceiver 
implementing time constrained services of Mac (802.15.4) layer.
So the ability to configure all these across serial driver would be very 
useful.

Best regards,

Re: serial performance

Hello,

Pierre-emmanuel Goudet wrote:

> Hi Dmitry, all,
> 
> As you said you will work in serial ZB protocol evolutions to allow
> better management of hardware capabilities of transceiver, would it be
> possible to add these kind of 'ops' in serial driver (hence protocol)
> and link them to specific 'ops' in the corresponding kernel device:
> 
> ==> For global ACK capabilities (as you discussed with Andrew)
> .set_auto_ack_(on/off)
> .set_auto_crc_(on/off)
> .set_mac_address (u64)
> .set_short_address (u16)
> .set_panid (u16)
> 
> ==> For 802.15.4 CSMA/CA tx capabilities: .set_auto_retry (on/off)
> .set_nb_csma_retries(u8)
> .set_nb_retries(u8)
> .set_min_backoff_exponent (u8)
> 
> Maybe all this and existing '.set' would also necessitate a 'get'
> capability also ?

I'd prefere to have one (or two) calls:
.config_aack(struct aack_config *, u32 valid)
.config_csma(struct csma_config *, u32 valid)

Installing in Ubuntu

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel@...
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel

Re: Installing in Ubuntu

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel@...
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel