Re: [OpenWrt-Devel] never ending story of patches not being applied
On Sat, 26 Jul 2008 22:51:33 -0400 Brian J. Murrell [EMAIL PROTECTED] wrote: On Sun, 2008-07-27 at 01:48 +0200, Frédéric Moulins wrote: It is not the case, but Trac remains a good system for tracking issues (categories, search), visualizing (diff, browse), and linking things together. Then Trac is not a good system. I'm certainly no bugzilla fanboy but given your observations about Trac I can say that bugzilla does all of this. At my workplace we use Bugzilla exactly for this purpose. Customers file bugs, developers create patches as bugzilla attachments. Other engineers comment on such patches in the same bug. Patches come to resolution and then they land on branches. It is clearly possible with Trac and it happens, look at : https://dev.openwrt.org/cgi-bin/trac.fcgi/ticket/2788 https://dev.openwrt.org/cgi-bin/trac.fcgi/ticket/3035 https://dev.openwrt.org/cgi-bin/trac.fcgi/ticket/3353 The bug even tracks which branches they land on. Yes, Bugzilla is very capable. Custom fields are something missing (I think) in Trac for example. Contributors should be advised to first submit patches in the issue tracker. Then, * if they have questions They being the patch submitters or the reviewers? They being submitters. while submitting their patches, they should be told to send patches to the mailing list by following the established conventions (To and CC, formatting, Signed-off-by,...) *and* with questions in order to get a review, nack, ack or can't look at it for the moment No. I disagree. Requiring contributors to post patches to more than one place is burdensome on the community you are trying to attract and confusing for new members. Choose one: a good tracking system or e-mail. Not both. I didn't express myself well. The only _required_ way should be posting contributions in the issue tracking system. Then, if contributors feel the need of a discussion about a patch they could be _advised_ to post it on the mailing-list (following the formatting). I found exactly what I mean in the madwifi contribution guide : Once your patch is ready for prime-time attach it to a ticket. These instructions(*) explain the details. In case you feel the need to discuss your patch, we suggest you start a new thread for that on the madwifi-devel mailing list and refer to the ticket that has the patch attached. Don't forget to explain what your patch is intended to do. (*) These instructions linking to a page explaining where to click and what to fill in. http://madwifi.org/wiki/DevDocs/PreparePatches * if someone asks for it (by commenting the issue), they should know they may have to re-submit the patch to the mailing list. Maybe in my case it's no great loss (but maybe for other contributors the loss would be greater and measurable) I would simply refuse to contribute patches if I knew the process were going to be so cumbersome. I agree, even if personally, I don't care about posting twice. When I submit something, I really want it to be integrated or that someone tells me no, that's stupid. Your goal here is to keep the barrier low and encourage contribution, not to make it a PITA to contribute. *And* to give devs/maintainers an easy way to keep track and review patches. That's why I insist on the mailing-list part but without making it a requirement, only an eventuality. I think it could work this way because patches needing a review - therefore a discussion, so emails - are either patch series or patches from people not experts on what they are modifying (first time, hack, not so much documentation...). In both case, patches are accompagnied by questions (either call for review, or expression of doubt) - therefore discussion... *But*, not so many submissions are patch series or complex hacks that could'nt be commented in Trac : think package updates, one liners. And people do not ask much questions because they tend to think if it works it is ok (at least, I do, most of the time). All of this tracking and questions and commenting, etc. can be carried out in a better tracker (on the assumption that your position that Trac doesn't do it well) and not have to be a bastardized process mishmash of half-Trac and half e-mail. Seriously, if a screwdriver isn't the right tool, adding a hammer to it doesn't make it right tool. I don't know any tracking system (except review-board) offering what the devs want: inline review of patches. So there is no right tool to satisfy them. (And I repeat, IMO, the only reason for the SubmittingPatches-byEmail guideline is inline review of patches) I agree most of the patch submissions can be commented in an issue tracker whith patches attached. Is it possible to let the submitter modify ticket properties after submission ? (like component: quite frustrating when ticket created with package instead of base system or else). It could help classification to be
[OpenWrt-Devel] [PATCH] mac80211 get_unaligned fi x under mipsel
mac80211 under mipsel complains about implicit declaration of
get_unaligned. the following patch deals with this issue.
Signed-off-by: Alexandros C. Couloumbis alex at ozo.com
---
diff -Nrub a/compat-wireless-2008-07-26/include/net/compat.h
b/compat-wireless-2008-07-26/include/net/compat.h
--- a/compat-wireless-2008-07-26/include/net/compat.h 2008-07-26
07:11:10.0 +0300
+++ b/compat-wireless-2008-07-26/include/net/compat.h 2008-07-27
12:58:28.0 +0300
@@ -678,6 +678,7 @@
# include linux/unaligned/le_struct.h
# include linux/unaligned/be_byteshift.h
# include linux/unaligned/generic.h
+# include mipsel-asm-generic-unaligned.h
#endif
#endif /* mips */
diff -Nrub
a/compat-wireless-2008-07-26/include/net/mipsel-asm-generic-unaligned.h
b/compat-wireless-2008-07-26/include/net/mipsel-asm-generic-unaligned.h
--- a/compat-wireless-2008-07-26/include/net/mipsel-asm-generic-unaligned.h
1970-01-01 02:00:00.0 +0200
+++ b/compat-wireless-2008-07-26/include/net/mipsel-asm-generic-unaligned.h
2008-07-27 12:58:42.0 +0300
@@ -0,0 +1,120 @@
+#ifndef _ASM_GENERIC_UNALIGNED_H_
+#define _ASM_GENERIC_UNALIGNED_H_
+
+/*
+ * For the benefit of those who are trying to port Linux to another
+ * architecture, here are some C-language equivalents.
+ *
+ * This is based almost entirely upon Richard Henderson's
+ * asm-alpha/unaligned.h implementation. Some comments were
+ * taken from David Mosberger's asm-ia64/unaligned.h header.
+ */
+
+#include linux/types.h
+
+/*
+ * The main single-value unaligned transfer routines.
+ */
+#define get_unaligned(ptr) \
+ __get_unaligned((ptr), sizeof(*(ptr)))
+#define put_unaligned(x,ptr) \
+ ((void)sizeof(*(ptr)=(x)),\
+ __put_unaligned((__force __u64)(x), (ptr), sizeof(*(ptr
+
+/*
+ * This function doesn't actually exist. The idea is that when
+ * someone uses the macros below with an unsupported size (datatype),
+ * the linker will alert us to the problem via an unresolved reference
+ * error.
+ */
+extern void bad_unaligned_access_length(void) __attribute__((noreturn));
+
+/*
+ * Elemental unaligned loads
+ */
+
+static inline __u64 __uldq(const __u64 *addr)
+{
+ const struct __una_u64 *ptr = (const struct __una_u64 *) addr;
+ return ptr-x;
+}
+
+static inline __u32 __uldl(const __u32 *addr)
+{
+ const struct __una_u32 *ptr = (const struct __una_u32 *) addr;
+ return ptr-x;
+}
+
+static inline __u16 __uldw(const __u16 *addr)
+{
+ const struct __una_u16 *ptr = (const struct __una_u16 *) addr;
+ return ptr-x;
+}
+
+/*
+ * Elemental unaligned stores
+ */
+
+static inline void __ustq(__u64 val, __u64 *addr)
+{
+ struct __una_u64 *ptr = (struct __una_u64 *) addr;
+ ptr-x = val;
+}
+
+static inline void __ustl(__u32 val, __u32 *addr)
+{
+ struct __una_u32 *ptr = (struct __una_u32 *) addr;
+ ptr-x = val;
+}
+
+static inline void __ustw(__u16 val, __u16 *addr)
+{
+ struct __una_u16 *ptr = (struct __una_u16 *) addr;
+ ptr-x = val;
+}
+
+#define __get_unaligned(ptr, size) ({ \
+ const void *__gu_p = ptr; \
+ __u64 __val;\
+ switch (size) { \
+ case 1: \
+ __val = *(const __u8 *)__gu_p; \
+ break; \
+ case 2: \
+ __val = __uldw(__gu_p); \
+ break; \
+ case 4: \
+ __val = __uldl(__gu_p); \
+ break; \
+ case 8: \
+ __val = __uldq(__gu_p); \
+ break; \
+ default:\
+ bad_unaligned_access_length(); \
+ }; \
+ (__force __typeof__(*(ptr)))__val; \
+})
+
+#define __put_unaligned(val, ptr, size)\
+({ \
+ void *__gu_p = ptr; \
+ switch (size) { \
+ case 1: \
+ *(__u8 *)__gu_p = (__force __u8)val;\
+ break; \
+ case 2: \
+ __ustw((__force __u16)val, __gu_p); \
+ break; \
+ case 4: \
+ __ustl((__force __u32)val, __gu_p); \
+ break; \
+ case 8: \
+ __ustq(val, __gu_p);\
+ break; \
+ default:\
+ bad_unaligned_access_length();
Re: [OpenWrt-Devel] never ending story of patches not being applied
On Sun, 2008-07-27 at 11:10 +0200, Frédéric Moulins wrote: On Sat, 26 Jul 2008 22:51:33 -0400 Brian J. Murrell [EMAIL PROTECTED] wrote: Then Trac is not a good system. I'm certainly no bugzilla fanboy but given your observations about Trac I can say that bugzilla does all of this. At my workplace we use Bugzilla exactly for this purpose. Customers file bugs, developers create patches as bugzilla attachments. Other engineers comment on such patches in the same bug. Patches come to resolution and then they land on branches. It is clearly possible with Trac and it happens, look at : https://dev.openwrt.org/cgi-bin/trac.fcgi/ticket/2788 https://dev.openwrt.org/cgi-bin/trac.fcgi/ticket/3035 https://dev.openwrt.org/cgi-bin/trac.fcgi/ticket/3353 Don't tell me, tell the OP. I was just saying that if what he is saying is true, then trac is not good enough. I have not really used Trac for full bug solution workflow so I don't know. The only _required_ way should be posting contributions in the issue tracking system. Then, if contributors feel the need of a discussion about a patch they could be _advised_ to post it on the mailing-list (following the formatting). Again, that is completely wrong. If the patch needs discussion it should happen all in one place. Otherwise you lose the context of the evolution of a patch. If I post a patch and then a revision and another revision, etc., people that come along after me might want to see why the patch evolved as it does. They should not have to try to go find that in the mailing list. I found exactly what I mean in the madwifi contribution guide : Once your patch is ready for prime-time attach it to a ticket. These instructions(*) explain the details. In case you ^^^ You. That means if the person posting the patch doesn't feel like it's actually a complete work, he can get help on the list before posting what should be a complete work to a tracking system. I agree with that. But once the patch owner thinks it's complete, (if a tracking system is desired -- and I'm not necessarily advocating that, just specifying the reasonable boundaries to the OP's ideas about using both tracking system and e-mail) and posts a patch to a tracking system, any peer review and followup should be done in the tracking system. This is all about workflow. Trust me. Take it from somebody who has been working full-time for years on an 10 year old open source project (so the processes are mature). Workflow in a tracking system can work, but you have to commit to it. No half-way efforts. (For patch review and tracking) Either use e-mail 100% of the time or tracking 100% of the time. Not both. feel the need to discuss your patch, we suggest you start a new thread for that on the madwifi-devel mailing list and refer to the ticket that has the patch attached. Don't forget to explain what your patch is intended to do. *And* to give devs/maintainers an easy way to keep track and review patches. Of course. I would suggest having them have to use a tracking system *and* e-mail for this process is overly cumbersome too. Rather than simply starting to make comments on a patch posted, now they have to go back to the patch owner and say ok, now I need you to post that same patch to the ML so that I can open it back up, try to remember what I wanted to critique and start writing my response. That's why I insist on the mailing-list part but without making it a requirement, only an eventuality. IMHO, it's all wrong. Choose one and commit to it. Seriously, as a patch reviewer, if I had to stop my review and ask the patch owner to post it again to the ML so that I can start my review all over again, I simply wouldn't. I want less work, not more. I don't know any tracking system (except review-board) offering what the devs want: inline review of patches. Bugzilla does it just fine. Patch owner attaches a patch to a ticket, then the reviewer then opens the attachment in a comment (that's a bugzilla feature) and goes about commenting, inline, on what he likes or doesn't like, the result being a new comment in the bug. So there is no right tool to satisfy them. I disagree. (And I repeat, IMO, the only reason for the SubmittingPatches-byEmail guideline is inline review of patches) As I've said, BZ does inline review just fine. This is a matter of configuration. Perhaps. I know BZ lets you do it. I don't know about Trac. But it seems that Trac already fails the review inline requirement anyway, so why bothering arguing about what else it doesn't do. I don't think it's worth the migration and configuration cost. To get inline review, where the only alternative is this mish-mash of a tracking system and e-mail that means more work for both posters and reviewers? I guess that's a call for the owners of the project. Whether they feel the migration effort is worth attracting and keeping contributors or not.
Re: [OpenWrt-Devel] [PATCH] use the in-kernel hostap-driver
This update fixes a backward compatibility issue. use kmod-hostap instead of kmod-net-hostap so we don't break dependencies such as hostap-utils and others. Signed-off-by: Alexandros C. Couloumbis alex at ozo.com --- diff -Nrub a/package/kernel/modules/wireless.mk b/package/kernel/modules/wireless.mk --- a/package/kernel/modules/wireless.mk2008-07-24 13:25:22.0 +0300 +++ b/package/kernel/modules/wireless.mk2008-07-27 17:35:13.0 +0300 @@ -133,6 +133,56 @@ $(eval $(call KernelPackage,net-airo)) +define KernelPackage/hostap + SUBMENU:=$(WIRELESS_MENU) + TITLE:=Host AP (Prism2/2.5/3 and WEP/TKIP/CCMP) driver + DEPENDS:[EMAIL PROTECTED] + KCONFIG:=CONFIG_HOSTAP + FILES:=$(LINUX_DIR)/drivers/net/wireless/hostap/hostap.$(LINUX_KMOD_SUFFIX) + AUTOLOAD:=$(call AutoLoad,50,hostap) +endef + +define KernelPackage/hostap/description + Shared driver code for IEEE 802.11b wireless cards based on + Intersil Prism2/2.5/3 chipset. This driver supports so called + Host AP mode that allows the card to act as an IEEE 802.11 + access point. + + See http://hostap.epitest.fi/ for more information about the + Host AP driver configuration and tools. This site includes + information and tools (hostapd and wpa_supplicant) for WPA/WPA2 + support. + + This option includes the base Host AP driver code that is shared by + different hardware models. You will also need to enable support for + PLX/PCI/CS version of the driver to actually use the driver. + + The driver can be compiled as a module and it will be called + hostap.ko. +endef + +$(eval $(call KernelPackage,hostap)) + +define KernelPackage/hostap-pci + SUBMENU:=$(WIRELESS_MENU) + TITLE:=Host AP driver for Prism2.5 PCI adaptors + DEPENDS:[EMAIL PROTECTED], kmod-hostap + KCONFIG:=CONFIG_HOSTAP_PCI + FILES:=$(LINUX_DIR)/drivers/net/wireless/hostap/hostap_pci.$(LINUX_KMOD_SUFFIX) + AUTOLOAD:=$(call AutoLoad,50,hostap_pci) +endef + +define KernelPackage/hostap-pci/description + Host AP driver's version for Prism2.5 PCI adaptors. + Host AP support for Prism2/2.5/3 IEEE 802.11b is required for this + driver and its help text includes more information about the Host AP + driver. + The driver can be compiled as a module and will be named + hostap_pci.ko. +endef + +$(eval $(call KernelPackage,hostap-pci)) + define KernelPackage/net-hermes SUBMENU:=$(WIRELESS_MENU) TITLE:=Hermes 802.11b chipset support ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] never ending story of patches not being applied
Trust me. Take it from somebody who has been working full-time for years on an 10 year old open source project (so the processes are mature). Workflow in a tracking system can work, but you have to commit to it. No half-way efforts. (For patch review and tracking) Either use e-mail 100% of the time or tracking 100% of the time. Not both. The first mail (from john) was about this choice : my vote as user and occasional submitter goes for tracking 100% of the time. feel the need to discuss your patch, we suggest you start a new thread for that on the madwifi-devel mailing list and refer to the ticket that has the patch attached. Don't forget to explain what your patch is intended to do. *And* to give devs/maintainers an easy way to keep track and review patches. Of course. I would suggest having them have to use a tracking system *and* e-mail for this process is overly cumbersome too. Rather than simply starting to make comments on a patch posted, now they have to go back to the patch owner and say ok, now I need you to post that same patch to the ML so that I can open it back up, try to remember what I wanted to critique and start writing my response. I agree this case is really cumbersome. I don't know any tracking system (except review-board) offering what the devs want: inline review of patches. Bugzilla does it just fine. Patch owner attaches a patch to a ticket, then the reviewer then opens the attachment in a comment (that's a bugzilla feature) and goes about commenting, inline, on what he likes or doesn't like, the result being a new comment in the bug. Oups, I never paid attention to it... :/ So there is no right tool to satisfy them. I disagree. You are right. Perhaps. I know BZ lets you do it. I don't know about Trac. But it seems that Trac already fails the review inline requirement anyway, so why bothering arguing about what else it doesn't do. I don't think it's worth the migration and configuration cost. To get inline review, where the only alternative is this mish-mash of a tracking system and e-mail that means more work for both posters and reviewers? I guess that's a call for the owners of the project. Whether they feel the migration effort is worth attracting and keeping contributors or not. Certainly not my call. Perhaps they read the list and they will agree with John for improving Trac configuration (or decide a bigger move), or state things stay the same : bugs in tracker, patches in mailing-list. Regards, fred ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Nanostation antenna selection support
On Sat, Jul 26, 2008 at 4:07 PM, Alberto Botti [EMAIL PROTECTED] wrote: Hi, I know that madwifi in OpenWrt doesn't support the Nanostation antenna selection* , but by looking at the DD-WRT changelog I've found an interesting patch antenna selection for ns2 http://svn.dd-wrt.com:8000/dd-wrt/changeset/9381 It looks like a small patch (apart from the whitespace noise) that messes with some gpio settings (of what? the board? the wireless chip?) and not directly with madwifi or the HAL. Anyone has more clues? Is a similar trick possible with OpenWrt or is DD-WRT using a different madwifi? I know I should've tried it myself but my own Nanostation still has to ship :( * the Nanostation is a low-cost router with a software selectable dual-polarity integrated antenna that appears to work only with Ubiquiti AirOS (stock OpenWrt with madwifi only enables the external connector) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel If you are using the internal antenna's on a ns2 they currently work via the madwifi rx(tx)antenna settings but to use the external antenna you need to install gpioctl and set softled to 0 for wifi0 in sysctl, then use gpioctl to set pin 7 low. Travis ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Nanostation antenna selection support
Il giorno dom, 27/07/2008 alle 13.49 -0500, Travis Kemen ha scritto: If you are using the internal antenna's on a ns2 they currently work via the madwifi rx(tx)antenna settings but to use the external antenna you need to install gpioctl and set softled to 0 for wifi0 in sysctl, then use gpioctl to set pin 7 low. Thanks for the answer. I'll try it as soon as my Nanostation arrives and hopefully prepare a patch for Kamikaze. Thanks ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] use the in-kernel hostap-driver
Hi Alexandros, Alexandros C. Couloumbis a écrit : According to the hostap driver author, : http://hostap.epitest.fi/ Host AP driver was added into the main kernel tree in Linux v2.6.14. The version in the kernel tree should be used instead of this external hostap-driver package. The external releases are only for older kernel versions and all the future development will be in the main kernel tree. This patch enebles the in-kernel hostap driver. the package/hostap-driver has to be removed first. Your patch is not needed, using in-kernel hostap modules is exactly what is being done on a 2.6 target in package/hostap-driver. -- Nico ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
