Hello. On Fri, 2011-06-17 at 20:30, Dmitry Eremin-Solenikov wrote: > > On 17.06.2011 19:55, Stefan Schmidt wrote: > >Hello. > > > >On Fri, 2011-06-17 at 19:31, Dmitry Eremin-Solenikov wrote: > >> > >>Sorry for ignoring this patch for sooo loooong. A bit better (IMHO) > >>patch was commited recently by Alexander/updated by me, which just > >>handles this few commands in a special > >>way. > > > >Can you sched some light one your plans regarding this project? > > > >It seems you just updated the git tree to 2.6.36 while completely > >ingnoring the 2.6.38 patches Jon posted long ago. I also never have > >seen the patches from Alexander on the list so you seem to have > >reviewed and approved them in private. > > > >Don't get me wrong here, I'm happy if you have time again to work on > >ieee802154/mac802154 and Alex works on the 6lowpan parts. I just would > >be interested in knowing if you plan to merge Jon's patches or move > >the git tree yourself to a more recent kernel and what kind of plans > >you have regarding mainline (or maybe staging). > > Please don't get me wrong :) I nearly don't have time to work on > IEEE/MAC 802.15.4. I might have some time, but not in near future. > For some time I was paid by my employee to work on this code. For > some time I was assigned to other projects. Currently (last few > months) Alexander (my colleague) is trying to dig into this project > and to contribute code. I'm supervising him on this (not so easy) > task. I really had no time to look for messages on this ML (and most > of other hobby projects were also stopped/delayed. Private life, > third kid).
Thanks for taking the time to write this up. Private life and especially kids should always have higher priority no doubt. :) But with a plan laid out as below we at least know where to work on and what we can and can not expect from you. Thats always better then poking in the dark. ;) > I plan to check Jon's patches, but it will require me to merge > v2.6.38 to my tree, apply patches on top of 2.6.38, find the > differences, etc. We might have time for this next week. Thanks. I know that at least Werner and myself are using the patches right now. I do it for example as I need another driver that hit mainline in 2.6.38. > Regarding global plans. We will try to modernise and cleanup things > a bit. Most probably we will merge one of recent kernels (2.6.38 is > a good candidate. another one will be 3.0-rc5 or 6). I'll try to > enforce some code changes in driver interface cleanup (removal of > single worker, handling everything, maybe cleanup of serial driver). > After this we will try to push at least basic drivers part and SMAC > protocol, so that it's possible to at least drive the hardware and > communicate with something. We might have a chance to push ieee > 802.15.4 monitor handling and (if/when) Alexander finishes that > 6lowpan code. He has some ideas on how to implement it in a more or > less generic way (not in the mac802154 layer). We don't have plans > to push whole mac802154 at this moment, because it's huge, > unfinished and non standard-compliant. Splitting it into smaller parts and trying to get them into shape and upstream step by step sounds like a reasonable plan for me. Especially getting the drivers over and have them useable with ieee802154 without the full mac802154 stack would help imho. > So, in the end: > > Plans for our linux-zigbee branch: > * update to recent kernels > * 6lowpan > * possible drivers interface cleanup > > Plans for mainline integration: > * drivers > * SMAC > * 6lowpan > * monitoring code Sounds good. > We will appreciate help with this project. And most probably all > other people from this ML also will. > Possible tasks: > * drivers interface cleanup. Drop that worker, implement locking. > * delayed messages (DATA REQUEST & ko). Messages should be passed to > coordinator for persistent storage and somehow restored/asked in case > of reboot. > * correct ASSOC procedure according to the standard (it isn't now!) > * correctly plug all MAC acceleration features (like auto-ACK, address > matching, etc.). Note, that mac802154 should handle things like > multiple interfaces on single radio and correctly disallow > accel combinations which are unsupported by hardware. > * We need a device which would support periodic beacons. Currently > whole stack is non-periodic-beaconed. > * New drivers/hardware to support (at86rf230, rf212, cc25xx chips, etc.) Depends on people havceing access to the hardware as usual. > * Implement generic messaging code which can work across rs-232, USB, > etc, like HCI interface for bluetooth. It should be extensible and > simple enough (don't look at current serial protocol, it's a mess). > * Did I miss something? o CSMA-CA in combination with some MAC acceleration features (Werner did mention this as well) o Re-transmit in case of missing ACK? As far as I understand the spec the ACK must arrive in a given timeframe and thats why most of the chips implement hardware ACKing. While the at86rf231 can handle retransmissions as well the cc2420 is not able to do this. Sounds like a mac8021544 feature to me. I will keep working on the cc2420 driver to get it reliable. Some patches should land here today. But its needs a lot more debugging and rewrite to work better (at all). I also got myself some of the ATUSB devices Werner designed (at86rf231 behind and ATmega32 and connected as USB stick to a linux host) and will help out there with the driver as well if needed. All this work is done for my diploma thesis and is only the groundwork for my actual work. Time has to show if I have some more spare cycles to tackle other tasks in the stack. regards Stefan Schmidt ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Linux-zigbee-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
