stge(4): enable TCP/UDP checksum offload
Here is a diff to enable the checksum offload support for stge(4). Tested with.. stge0 at pci0 dev 3 function 0 D-Link DGE-550T rev 0x07 Index: if_stge.c === RCS file: /home/cvs/src/sys/dev/pci/if_stge.c,v retrieving revision 1.54 diff -u -p -r1.54 if_stge.c --- if_stge.c 18 Oct 2012 21:44:21 - 1.54 +++ if_stge.c 4 Nov 2012 06:35:01 - @@ -376,7 +376,8 @@ stge_attach(struct device *parent, struc IFQ_SET_MAXLEN(ifp-if_snd, STGE_NTXDESC - 1); IFQ_SET_READY(ifp-if_snd); - ifp-if_capabilities = IFCAP_VLAN_MTU; + ifp-if_capabilities = IFCAP_VLAN_MTU | IFCAP_CSUM_IPv4 | + IFCAP_CSUM_TCPv4 | IFCAP_CSUM_UDPv4; #if NVLAN 0 ifp-if_capabilities |= IFCAP_VLAN_HWTAGGING; @@ -399,14 +400,6 @@ stge_attach(struct device *parent, struc sc-sc_DMACtrl |= DMAC_MWIDisable; #endif -#ifdef STGE_CHECKSUM - /* -* We can do IPv4/TCPv4/UDPv4 checksums in hardware. -*/ - sc-sc_arpcom.ac_if.if_capabilities |= IFCAP_CSUM_IPv4 | - IFCAP_CSUM_TCPv4 | IFCAP_CSUM_UDPv4; -#endif - /* * Attach the interface. */ @@ -556,7 +549,6 @@ stge_start(struct ifnet *ifp) totlen += dmamap-dm_segs[seg].ds_len; } -#ifdef STGE_CHECKSUM /* * Initialize checksumming flags in the descriptor. * Byte-swap constants so the compiler can optimize. @@ -568,7 +560,6 @@ stge_start(struct ifnet *ifp) csum_flags |= TFD_TCPChecksumEnable; else if (m0-m_pkthdr.csum_flags M_UDP_CSUM_OUT) csum_flags |= TFD_UDPChecksumEnable; -#endif /* * Initialize the descriptor and give it to the chip. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
jme(4): enable TCP/UDP checksum offload
Here is a diff to enable the checksum offload support for jme(4). Tested with.. jme0 at pci4 dev 0 function 0 JMicron JMC250 rev 0x11 Index: if_jme.c === RCS file: /home/cvs/src/sys/dev/pci/if_jme.c,v retrieving revision 1.28 diff -u -p -r1.28 if_jme.c --- if_jme.c22 Oct 2012 09:19:17 - 1.28 +++ if_jme.c4 Nov 2012 06:40:12 - @@ -614,12 +614,8 @@ jme_attach(struct device *parent, struct IFQ_SET_READY(ifp-if_snd); strlcpy(ifp-if_xname, sc-sc_dev.dv_xname, IFNAMSIZ); - ifp-if_capabilities = IFCAP_VLAN_MTU; - -#ifdef JME_CHECKSUM - ifp-if_capabilities |= IFCAP_CSUM_IPv4 | IFCAP_CSUM_TCPv4 | - IFCAP_CSUM_UDPv4; -#endif + ifp-if_capabilities = IFCAP_VLAN_MTU | IFCAP_CSUM_IPv4 | + IFCAP_CSUM_TCPv4 | IFCAP_CSUM_UDPv4; #if NVLAN 0 ifp-if_capabilities |= IFCAP_VLAN_HWTAGGING; -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
vge(4): Add flow control support
Here is a diff to add flow control support to vge(4).
Tested with..
vge0 at pci2 dev 4 function 0 VIA VT612x rev 0x11
ciphy0 at vge0 phy 1: CS8201 10/100/1000TX PHY, rev. 1
OK?
Index: if_vge.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_vge.c,v
retrieving revision 1.51
diff -u -p -r1.51 if_vge.c
--- if_vge.c22 Jun 2011 16:44:27 - 1.51
+++ if_vge.c22 Oct 2012 08:22:55 -
@@ -812,7 +812,7 @@ vge_attach(struct device *parent, struct
ifmedia_init(sc-sc_mii.mii_media, 0,
vge_ifmedia_upd, vge_ifmedia_sts);
mii_attach(self, sc-sc_mii, 0x, MII_PHY_ANY,
- MII_OFFSET_ANY, 0);
+ MII_OFFSET_ANY, MIIF_DOPAUSE);
if (LIST_FIRST(sc-sc_mii.mii_phys) == NULL) {
printf(%s: no PHY found!\n, sc-vge_dev.dv_xname);
ifmedia_add(sc-sc_mii.mii_media, IFM_ETHER|IFM_MANUAL,
@@ -1630,9 +1630,16 @@ vge_init(struct ifnet *ifp)
/* Init the multicast filter. */
vge_setmulti(sc);
- /* Enable flow control */
-
- CSR_WRITE_1(sc, VGE_CRS2, 0x8B);
+ /* Initialize pause timer. */
+ CSR_WRITE_2(sc, VGE_TX_PAUSE_TIMER, 0x);
+ /*
+* Initialize flow control parameters.
+* TX XON high threshold : 48
+* TX pause low threshold : 24
+* Disable half-duplex flow control
+*/
+ CSR_WRITE_1(sc, VGE_CRC2, 0xFF);
+ CSR_WRITE_1(sc, VGE_CRS2, VGE_CR2_XON_ENABLE | 0x0B);
/* Enable jumbo frame reception (if desired) */
@@ -1768,6 +1775,16 @@ vge_miibus_statchg(struct device *dev)
sc-vge_dev.dv_xname, IFM_SUBTYPE(ife-ifm_media));
break;
}
+
+ /*
+* 802.3x flow control
+ */
+ CSR_WRITE_1(sc, VGE_CRC2, VGE_CR2_FDX_TXFLOWCTL_ENABLE |
+ VGE_CR2_FDX_RXFLOWCTL_ENABLE);
+ if ((IFM_OPTIONS(mii-mii_media_active) IFM_ETH_TXPAUSE) != 0)
+ CSR_WRITE_1(sc, VGE_CRS2, VGE_CR2_FDX_TXFLOWCTL_ENABLE);
+ if ((IFM_OPTIONS(mii-mii_media_active) IFM_ETH_RXPAUSE) != 0)
+ CSR_WRITE_1(sc, VGE_CRS2, VGE_CR2_FDX_RXFLOWCTL_ENABLE);
}
int
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
athn@usb: fixup detach panic
attach fails early in case there's no firmware, but
athn_detach does ieee80211_ifdetach and if_detach
regardless of whether ifnet part got setup correctly
leading to a free of an unallocated memory and a
panic.
the following diff follows an established practice
in the other drivers and fixes the problem here.
tested on this device:
athn0 at uhub0 port 3 NETGEAR WNA WNA1100 rev 2.00/1.08 addr 2
athn0: AR9271 rev 1 (1T1R), ROM rev 15, address 20:4e:7f:d9:65:2f
ok?
Index: athn.c
===
RCS file: /home/cvs/src/sys/dev/ic/athn.c,v
retrieving revision 1.74
diff -u -p -u -p -r1.74 athn.c
--- athn.c 20 Oct 2012 09:54:20 - 1.74
+++ athn.c 1 Nov 2012 16:33:53 -
@@ -396,8 +396,10 @@ athn_detach(struct athn_softc *sc)
if (sc-eep != NULL)
free(sc-eep, M_DEVBUF);
- ieee80211_ifdetach(ifp);
- if_detach(ifp);
+ if (ifp-if_softc != NULL) {
+ ieee80211_ifdetach(ifp);
+ if_detach(ifp);
+ }
}
#if NBPFILTER 0
Re: athn@usb: fixup detach panic
On Tue, Nov 06, 2012 at 11:32:19AM +0100, Mike Belopuhov wrote:
attach fails early in case there's no firmware, but
athn_detach does ieee80211_ifdetach and if_detach
regardless of whether ifnet part got setup correctly
leading to a free of an unallocated memory and a
panic.
the following diff follows an established practice
in the other drivers and fixes the problem here.
tested on this device:
athn0 at uhub0 port 3 NETGEAR WNA WNA1100 rev 2.00/1.08 addr 2
athn0: AR9271 rev 1 (1T1R), ROM rev 15, address 20:4e:7f:d9:65:2f
ok?
It seems more appropriate to handle this problem entirely within
the USB-specific layer of the driver, rather than within dev/ic/athn.c.
If loading the firmware fails, athn_usb_attachhook() doesn't even
call athn_attach(). This is what your fix is compensating for. I believe
athn_usb_detach() shouldn't be calling athn_detach() unconditionally.
I fixed a similar problem for acx(4) cardbus cards once, where ejecting
a card that had failed to attach half way through paniced the kernel.
This was in r1.12 of dev/cardbus/if_acx_cardbus.c, which looked like this:
Index: if_acx_cardbus.c
===
RCS file: /cvs/src/sys/dev/cardbus/if_acx_cardbus.c,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -p -r1.11 -r1.12
--- if_acx_cardbus.c10 Nov 2006 20:20:04 - 1.11
+++ if_acx_cardbus.c26 Feb 2009 23:03:05 - 1.12
@@ -1,4 +1,4 @@
-/* $OpenBSD: if_acx_cardbus.c,v 1.11 2006/11/10 20:20:04 damien Exp $ */
+/* $OpenBSD: if_acx_cardbus.c,v 1.12 2009/02/26 23:03:05 stsp Exp $ */
/*
* Copyright (c) 2006 Claudio Jeker clau...@openbsd.org
@@ -77,6 +77,8 @@ struct acx_cardbus_softc {
bus_space_tag_t sc_io_bt;
bus_space_handle_t sc_io_bh;
bus_size_t sc_iomapsize;
+
+ int sc_acx_attached;
};
intacx_cardbus_match(struct device *, void *, void *);
@@ -171,7 +173,8 @@ acx_cardbus_attach(struct device *parent
else
acx100_set_param(sc);
- acx_attach(sc);
+ error = acx_attach(sc);
+ csc-sc_acx_attached = error == 0;
Cardbus_function_disable(ct);
}
@@ -186,9 +189,11 @@ acx_cardbus_detach(struct device *self,
cardbus_function_tag_t cf = ct-ct_cf;
int error, b1 = CARDBUS_BASE0_REG, b2 = CARDBUS_BASE1_REG;
- error = acx_detach(sc);
- if (error != 0)
- return (error);
+ if (csc-sc_acx_attached) {
+ error = acx_detach(sc);
+ if (error != 0)
+ return (error);
+ }
/* unhook the interrupt handler */
if (csc-sc_ih != NULL) {
Index: athn.c
===
RCS file: /home/cvs/src/sys/dev/ic/athn.c,v
retrieving revision 1.74
diff -u -p -u -p -r1.74 athn.c
--- athn.c20 Oct 2012 09:54:20 - 1.74
+++ athn.c1 Nov 2012 16:33:53 -
@@ -396,8 +396,10 @@ athn_detach(struct athn_softc *sc)
if (sc-eep != NULL)
free(sc-eep, M_DEVBUF);
- ieee80211_ifdetach(ifp);
- if_detach(ifp);
+ if (ifp-if_softc != NULL) {
+ ieee80211_ifdetach(ifp);
+ if_detach(ifp);
+ }
}
#if NBPFILTER 0
upstream vendors and why they can be really harmful
Basically, we have a pattern, mostly observed with kde (and a bit with gnome) which is really harmful for us. Those vendors say we're not in the distribution business, distribution problems will be handled by OS vendors. We can break compatibility to advance, and not think about it, this is not a problem. This is a mindset we need to fight, and this has to be a grass-roots movement. The main effect of THAT attitude is to *HURT* the opensource community, big time. It's as harmful as the patent portfolio of big business. Basically, it precludes smaller players from playing on a level field. As soon as you're different enough (and that's mostly NOT linux these days), you can't keep up. Those distribution problems are LARGE. They occupy a few people in our team FULLTIME with respect to gnome, they're the reason we still DON'T have a full kde4 in our tree (hopefully to be addressed shortly), and they're the reason why sometimes we do drop old stuff (like killing gtk+1, and people really wanting to kill some gtk2/qt3 stuff). It takes a lot of manpower to address complex distribution issues. If you don't have tens of people, it becomes more and more of a losing battle, actually... It's also quickly turning Posix and Unix into a travesty: either you have the linux goodies, or you don't. And if you don't, you can forget anything modern... in some cases, you even have some people, who are PAID by some vendors, agressively pushing GRATUITOUS, non compatible changes. I won't say names, but you guys can fill the blanks in. I'm pretty sure there's a lot of good intention behind the progress in recent desktops. But this is turning the field of OS distributions into a wasteland. Either you're a modern linux with pulseaudio and pam and systemd, or you're dying. So much for the pionneer spirit of opensource, where you were free to innovate and do cool things, and more or less have interesting software able to run on your machine...
Re: upstream vendors and why they can be really harmful
On Tue, Nov 06, 2012 at 01:38:32PM +0100, Marc Espie wrote: Basically, we have a pattern, mostly observed with kde (and a bit with gnome) which is really harmful for us. Those vendors say we're not in the distribution business, distribution problems will be handled by OS vendors. We can break compatibility to advance, and not think about it, this is not a problem. This is a mindset we need to fight, and this has to be a grass-roots movement. The main effect of THAT attitude is to *HURT* the opensource community, big time. It's as harmful as the patent portfolio of big business. Basically, it precludes smaller players from playing on a level field. As soon as you're different enough (and that's mostly NOT linux these days), you can't keep up. Those distribution problems are LARGE. They occupy a few people in our team FULLTIME with respect to gnome, they're the reason we still DON'T have a full kde4 in our tree (hopefully to be addressed shortly), and they're the reason why sometimes we do drop old stuff (like killing gtk+1, and people really wanting to kill some gtk2/qt3 stuff). It takes a lot of manpower to address complex distribution issues. If you don't have tens of people, it becomes more and more of a losing battle, actually... It's also quickly turning Posix and Unix into a travesty: either you have the linux goodies, or you don't. And if you don't, you can forget anything modern... in some cases, you even have some people, who are PAID by some vendors, agressively pushing GRATUITOUS, non compatible changes. I won't say names, but you guys can fill the blanks in. I'm pretty sure there's a lot of good intention behind the progress in recent desktops. But this is turning the field of OS distributions into a wasteland. Either you're a modern linux with pulseaudio and pam and systemd, or you're dying. So much for the pionneer spirit of opensource, where you were free to innovate and do cool things, and more or less have interesting software able to run on your machine... One could answer you that the BSD community is not involved enough with upstream. 99% of the development is done on Linux by developers using Linux -- if you want that to change, some !linux people should get involved in outside projects... I'm not saying I agree nor disagree with that statement, I'm just being the devil's advocate. -- Antoine
Re: upstream vendors and why they can be really harmful
Apparently branding as a priority by some devs, is a major reason. I can't believe a Gnome dev said he hadn't heard of XFCE to a transmission dev! http://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotting-in-threes/ in some cases, you even have some people, who are PAID by some vendors, agressively pushing GRATUITOUS, non compatible changes. I won't say names, but you guys can fill the blanks in. I'm pretty sure there's a lot of good intention behind the progress in recent desktops. But this is turning the field of OS distributions into a wasteland. Either you're a modern linux with pulseaudio and pam and systemd, or you're dying. So much for the pionneer spirit of opensource, where you were free to innovate and do cool things, and more or less have interesting software able to run on your machine... It could well end up the other way around, with systemd dying. It does far too much and most of which is pointless in order to gain traction but also limiting it's scope and so success unless it is forked or radically changed of course. The amount of code running as root is rediculous too. Even Redhat devs have said it offers little and it certainly causes major problems even for Linux. The Linux communities are still keeping some freedom (Gentoo, Debian). It's said Debian is just because of HURD but I don't think that's true, though the argument would be long. Rather than spending time on these, are trinity and mate etc.. worth looking at? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: upstream vendors and why they can be really harmful
On Tue, Nov 06, 2012 at 01:38:32PM +0100, Marc Espie wrote: Basically, we have a pattern, mostly observed with kde (and a bit with gnome) which is really harmful for us. ... Relevant LWN.net article: http://lwn.net/Articles/520892/
Re: upstream vendors and why they can be really harmful
On Tue, Nov 06, 2012 at 01:15:04PM +, Kevin Chadwick wrote: Rather than spending time on these, are trinity and mate etc.. worth looking at? I'm pretty sure trinity is worth looking at, haven't had nearly enough time to do so, especially since it's yet another build system you need to dive into.
Re: upstream vendors and why they can be really harmful
On Tue, Nov 06, 2012 at 01:43:50PM +0100, Antoine Jacoutot wrote: One could answer you that the BSD community is not involved enough with upstream. 99% of the development is done on Linux by developers using Linux -- if you want that to change, some !linux people should get involved in outside projects... I'm not saying I agree nor disagree with that statement, I'm just being the devil's advocate. Been there, done that... I've spent quite some time trying to work with the FSF on tools like GCC. At some point, I've mostly given up, I'm not patient enough. The GCC rules were as follows: - all development happens on their -current branch, which was often a few years from making a release. - it takes sometimes months until you get an answer on a patch. Very often, it's about some style nits that they could have given you right away. (but since you're not a 1st tier, nor 2nd tier platform, be already happy you got an answer). - by which time, -current does no longer compile on your platform, due to some other issue, which obviously doesn't affect linux, but that you have no way to fix, as it is deep within the compiler. File a bug-report.. - with luck, another 3 months later, somebody fixed -current, and it works again. By which time your initial patch (which was never committed) no longer applies at all, and you're stranded, having to do it all over again. - also, you have an assurance that that work will only show up in released versions a few years from now, as they never backport anything but very critical fixes to old versions (and by definition, OpenBSD is never critical). they also made some technical choice, such as making it impossible to build gcc without gnu-make, that we never had sufficient clout to battle... I'm very happy to let pascal@ or kettenis@ deal with them directly. I don't have the patience to fight that particular fight anymore...
Re: upstream vendors and why they can be really harmful
On 11/06/2012 03:45 PM, Marc Espie wrote: On Tue, Nov 06, 2012 at 01:43:50PM +0100, Antoine Jacoutot wrote: One could answer you that the BSD community is not involved enough with upstream. 99% of the development is done on Linux by developers using Linux -- if you want that to change, some !linux people should get involved in outside projects... I'm not saying I agree nor disagree with that statement, I'm just being the devil's advocate. Been there, done that... I've spent quite some time trying to work with the FSF on tools like GCC. At some point, I've mostly given up, I'm not patient enough. The GCC rules were as follows: - all development happens on their -current branch, which was often a few years from making a release. - it takes sometimes months until you get an answer on a patch. Very often, it's about some style nits that they could have given you right away. (but since you're not a 1st tier, nor 2nd tier platform, be already happy you got an answer). - by which time, -current does no longer compile on your platform, due to some other issue, which obviously doesn't affect linux, but that you have no way to fix, as it is deep within the compiler. File a bug-report.. - with luck, another 3 months later, somebody fixed -current, and it works again. By which time your initial patch (which was never committed) no longer applies at all, and you're stranded, having to do it all over again. - also, you have an assurance that that work will only show up in released versions a few years from now, as they never backport anything but very critical fixes to old versions (and by definition, OpenBSD is never critical). they also made some technical choice, such as making it impossible to build gcc without gnu-make, that we never had sufficient clout to battle... I'm very happy to let pascal@ or kettenis@ deal with them directly. I don't have the patience to fight that particular fight anymore... forgive my curiosity, but is pcc anywhere near?
Re: upstream vendors and why they can be really harmful
Lets be honest, half the problem goes away if Lennart stops hacking.
Re: upstream vendors and why they can be really harmful
On Tue, Nov 06, 2012 at 01:38:32PM +0100, Marc Espie wrote: in some cases, you even have some people, who are PAID by some vendors, agressively pushing GRATUITOUS, non compatible changes. I won't say names, but you guys can fill the blanks in. I'll fill in redhat, making upstream support even for older ATI video cards effectively Linux-only by removing all UMS support from the X driver: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=50689ec8dbd4a68527b2ac16cecac298b8d441d0 I'm not an X hacker so I might have misunderstood the impact of this but on the surface it looks like a move that's bad for everyone but Linux. Couldn't they at least have left the existing and working UMS stuff alone so others could still easily upgrade the driver to get bug fixes? On the bright side, somebody seems to have finally figured out the zaphod mode issue: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=20bfc652ce40008ea561db2984bccf137409c7fd
Re: [cwm 1/1] Add a menu to search and call internal functions.
Can you please provide a unified cvs diff?
I've not tried this patch but I have some comments (see below).
Useful for those times you want to use an unbound function, but even
when the function is bound to something you haven't memorized yet it
can be faster than lookup up the keybinding in the manual. Bound to
CM-/ by default.
[...]
+struct func name_to_kbfunc[] = {
{ lower, kbfunc_client_lower, KBFLAG_NEEDCLIENT, {0} },
{ raise, kbfunc_client_raise, KBFLAG_NEEDCLIENT, {0} },
{ search, kbfunc_client_search, 0, {0} },
+ { funcsearch, kbfunc_func_search, KBFLAG_NEEDCLIENT, {0} },
{ menusearch, kbfunc_menu_search, 0, {0} },
{ hide, kbfunc_client_hide, KBFLAG_NEEDCLIENT, {0} },
{ cycle, kbfunc_client_cycle, 0, {.i = CWM_CYCLE} },
@@ -399,6 +396,7 @@
{.i = (CWM_LEFT|CWM_PTRMOVE|CWM_BIGMOVE)} },
{ bigptrmoveright, kbfunc_moveresize, 0,
{.i = (CWM_RIGHT|CWM_PTRMOVE|CWM_BIGMOVE)} },
+ { NULL, NULL, 0, {0} }
Why do you insist on adding this? Why not just use nitems?
@@ -488,7 +486,8 @@
return;
for (iter = 0; iter nitems(name_to_kbfunc); iter++) {
- if (strcmp(name_to_kbfunc[iter].tag, binding) != 0)
+ if (name_to_kbfunc[iter].tag == NULL ||
+ strcmp(name_to_kbfunc[iter].tag, binding) != 0)
continue;
See? Now you have to add more code because you broke something.
Index: cwm/kbfunc.c
===
--- cwm.orig/kbfunc.c 2012-11-05 10:25:37.577424801 -0600
+++ cwm/kbfunc.c 2012-11-05 14:17:27.164487245 -0600
@@ -174,6 +174,35 @@
}
void
+kbfunc_func_search(struct client_ctx *cc, union arg *arg)
+{
+ struct screen_ctx *sc = cc-sc;
+ struct func *func;
+ struct menu *mi;
+ struct menu_qmenuq;
+
+ TAILQ_INIT(menuq);
+
+ for (func = name_to_kbfunc; func-tag != NULL; func++) {
Why not
for (iter = 0; iter nitems(name_to_kbfunc); iter++) {
func = name_to_kbfunc[iter]; /* if you want to use func */
then you don't need the last NULL entry in the array or add code
to not break existing code.
+ if ((mi = menu_filter(sc, menuq, function, NULL, 0,
+ search_match_text, NULL)) != NULL) {
+ func = (struct func *)mi-ctx;
+ (*func-handler)(cc, func-argument);
func-handler(... is fine but some people prefer the pre-ANSI
C style, (*func-handler)(... ... Just a tiny nit. YMMV.
Re: [cwm 1/1] Add a menu to search and call internal functions.
I haven't caught-up, nor reviewed anything else yet, but comments
inline:
On Tue 2012.11.06 at 16:11 +0100, Thomas Pfaff wrote:
Can you please provide a unified cvs diff?
'cvs diff -uNp' is best...
[...]
for (iter = 0; iter nitems(name_to_kbfunc); iter++) {
- if (strcmp(name_to_kbfunc[iter].tag, binding) != 0)
+ if (name_to_kbfunc[iter].tag == NULL ||
+ strcmp(name_to_kbfunc[iter].tag, binding) != 0)
continue;
I too would prefer to use nitems, to be consistent with the rest of the
code. Also reduces the number of gratuitous changes, and of course the
size of the diff.
+ if ((mi = menu_filter(sc, menuq, function, NULL, 0,
+ search_match_text, NULL)) != NULL) {
+ func = (struct func *)mi-ctx;
+ (*func-handler)(cc, func-argument);
Likewise, as mentioned, consistency with the rest is best.
Re: upstream vendors and why they can be really harmful
On Tue, Nov 6, 2012 at 1:38 PM, Marc Espie es...@nerim.net wrote: This is a mindset we need to fight, and this has to be a grass-roots movement. I agree with most of your statement, but for a grass-root movement you will need to attract a lot of people. Otherwise you will move exactly *nothing*. And let's be honest here - some people involved in OpenBSD are not the most open-minded people in FOSS. They behave so elitist they scare a lot of folks away and to gain momentum you will need to deal also with people that are probably not as knowledegable as you might want. If you want people to gain traction you will need to reduce some standards... just my 2 ct Lars
Re: upstream vendors and why they can be really harmful
On 2012 Nov 06 (Tue) at 16:45:17 +0100 (+0100), Lars von den Driesch wrote: :If you want people to gain traction you will need to :reduce some standards... This is exactly what happened in Linux-land, and brought us to this place in the first point. -- Math is like love -- a simple idea but it can get complicated. -- R. Drabek
Re: upstream vendors and why they can be really harmful
On Tue, Nov 06, 2012 at 04:45:17PM +0100, Lars von den Driesch wrote: On Tue, Nov 6, 2012 at 1:38 PM, Marc Espie es...@nerim.net wrote: This is a mindset we need to fight, and this has to be a grass-roots movement. I agree with most of your statement, but for a grass-root movement you will need to attract a lot of people. Otherwise you will move exactly *nothing*. And let's be honest here - some people involved in OpenBSD are not the most open-minded people in FOSS. They behave so elitist they scare a lot of folks away and to gain momentum you will need to deal also with people that are probably not as knowledegable as you might want. If you want people to gain traction you will need to reduce some standards... just my 2 ct Lars Actually, I am just giving food for thought, it's a long-time issue I've seen creep up again and again... so I've tried to formalize it up to some extent. I'm not going to go out and do anything such as organize such a movement: I already don't have enough time to do everything I wish to do, and I'm pretty sure my time is much better employed writing code and fixing issues within OpenBSD, or going to conferences and explaining to people why what we do is still relevant. Also, my day job involves some teaching (a lot), so doing more of that is not really fun. So, hey, do whatever you want with that. Apart from the proverbial curmudgeons, there are LOTS of nice people in the OpenBSD developer community, who are fairly open to a lot of stuff... I wouldn't be there if that weren't the case.
Re: upstream vendors and why they can be really harmful
On Tue, Nov 6, 2012 at 5:10 PM, Peter Hessler phess...@theapt.org wrote: On 2012 Nov 06 (Tue) at 16:45:17 +0100 (+0100), Lars von den Driesch wrote: This is exactly what happened in Linux-land, and brought us to this place in the first point. I know :-) And I understand this - but in this situation I believe you have to choose between 2 devils. If you stay in your niche you can just watch the idiocy happening outside, but you will have absolutely no way of influencing it. Lars
Re: upstream vendors and why they can be really harmful
Hi Marc On Tue, Nov 6, 2012 at 5:16 PM, Marc Espie es...@nerim.net wrote: So, hey, do whatever you want with that. Apart from the proverbial curmudgeons, there are LOTS of nice people in the OpenBSD developer community, who are fairly open to a lot of stuff... I wouldn't be there if that weren't the case. Oh, I didn't want to generalize on the niceness (or lack of) in OpenBSD - sorry if it sounded like that. As in every group there are people more friendly than others :-) From your point of view everybody is nice to you ;-) You are one of the core devs - for people probably not that knowledgable as you and coming from outside it might leave a different impression. Again, I am just saying... ;-) Lars
Re: upstream vendors and why they can be really harmful
From your point of view everybody is nice to you ;-) I'm not! Miod
Re: [cwm 1/1] Add a menu to search and call internal functions.
Hey, dude-
Can you please provide a unified cvs diff?
The first patches I sent last week were cvs diffs, but I saw quilt
was recently added to ports to I switched to using it to manage all
of the patches (I have a few other things I'm working on, too, which
I haven't sent out for review yet).
Does anyone know if quilt can delegate diffing to cvs? I'll
investigate some more and see if I can get quilt to do this
automatically.
Why do you insist on adding this? Why not just use nitems?
...
See? Now you have to add more code because you broke something.
...
Why not
for (iter = 0; iter nitems(name_to_kbfunc); iter++) {
func = name_to_kbfunc[iter]; /* if you want to use func */
then you don't need the last NULL entry in the array or add code
to not break existing code.
See: http://c-faq.com/decl/extarraysize.html
The diff moves the declaration of name_to_kbfunc[] to calmwm.h and
externs it for use in kbfunc.c, but it's still defined in conf.c.
+ if ((mi = menu_filter(sc, menuq, function, NULL, 0,
+ search_match_text, NULL)) != NULL) {
+ func = (struct func *)mi-ctx;
+ (*func-handler)(cc, func-argument);
func-handler(... is fine but some people prefer the pre-ANSI
C style, (*func-handler)(... ... Just a tiny nit. YMMV.
I don't have a preference, I just followed the style used elsewhere
in cwm.
Thanks for the feedback!
Best,
Kent
Re: upstream vendors and why they can be really harmful
On Tue, Nov 6, 2012 at 1:43 PM, Antoine Jacoutot ajacou...@bsdfrog.org wrote: On Tue, Nov 06, 2012 at 01:38:32PM +0100, Marc Espie wrote: Basically, we have a pattern, mostly observed with kde (and a bit with gnome) which is really harmful for us. Those vendors say we're not in the distribution business, distribution problems will be handled by OS vendors. We can break compatibility to advance, and not think about it, this is not a problem. This is a mindset we need to fight, and this has to be a grass-roots movement. The main effect of THAT attitude is to *HURT* the opensource community, big time. It's as harmful as the patent portfolio of big business. Basically, it precludes smaller players from playing on a level field. As soon as you're different enough (and that's mostly NOT linux these days), you can't keep up. Those distribution problems are LARGE. They occupy a few people in our team FULLTIME with respect to gnome, they're the reason we still DON'T have a full kde4 in our tree (hopefully to be addressed shortly), and they're the reason why sometimes we do drop old stuff (like killing gtk+1, and people really wanting to kill some gtk2/qt3 stuff). It takes a lot of manpower to address complex distribution issues. If you don't have tens of people, it becomes more and more of a losing battle, actually... It's also quickly turning Posix and Unix into a travesty: either you have the linux goodies, or you don't. And if you don't, you can forget anything modern... in some cases, you even have some people, who are PAID by some vendors, agressively pushing GRATUITOUS, non compatible changes. I won't say names, but you guys can fill the blanks in. I'm pretty sure there's a lot of good intention behind the progress in recent desktops. But this is turning the field of OS distributions into a wasteland. Either you're a modern linux with pulseaudio and pam and systemd, or you're dying. So much for the pionneer spirit of opensource, where you were free to innovate and do cool things, and more or less have interesting software able to run on your machine... One could answer you that the BSD community is not involved enough with upstream. 99% of the development is done on Linux by developers using Linux -- if you want that to change, some !linux people should get involved in outside projects... I'm not saying I agree nor disagree with that statement, I'm just being the devil's advocate. -- Antoine I was reading your post to Gnome mailing list and answers from devs and it's hard to find proper words on their clever answers. They are probably not much aware about your work in M:tier with Gnome, do they? They don't simply care about downstream and they already decided (most of them). Do you have some escape plan for that like some BSD licensed window manager as you are tweaking on Gnome desktop for OpenBSD anyway like WiFi GUI app? I think (can be completely out of course) that there may be pretty good interest in BSD community for some desktop like you are doing for implementation at homes, jobs and so on which is not so different from what people know from other platforms. Not like getting over 1% of Linux market share, but simply, clean and stable desktop for corporate world which can help with more attraction.
Re: [cwm 1/1] Add a menu to search and call internal functions.
Hey, dude-
I too would prefer to use nitems, to be consistent with the rest of the
code. Also reduces the number of gratuitous changes, and of course the
size of the diff.
I chose the guard element approach because it leads to the smallest diff,
but I can move the definition of name_to_kbfunc[] from conf.c to a header
if you prefer.
+ if ((mi = menu_filter(sc, menuq, function, NULL, 0,
+ search_match_text, NULL)) != NULL) {
+ func = (struct func *)mi-ctx;
+ (*func-handler)(cc, func-argument);
Likewise, as mentioned, consistency with the rest is best.
I wrote the above specifically to be consistent with other parts of cwm;
see: xevents.c:261 and xevents.c:314.
Thanks for the feedback!
Best,
Kent
Re: upstream vendors and why they can be really harmful
On Tue, Nov 06, 2012 at 01:15:04PM +, Kevin Chadwick wrote: It could well end up the other way around, with systemd dying. It does far too much and most of which is pointless in order to gain traction but also limiting it's scope and so success unless it is forked or radically changed of course. The amount of code running as root is rediculous too. Even Redhat devs have said it offers little and it certainly causes major problems even for Linux. Some RH guys don't like only from sysadmin or job point of view, in F19 there should be no /var/log/messages or they are worried about how to support environments and apps which uses this files to parse it. This also contains big finantial level but as Fedora is playground nobody cares there much about this topic. Most Linux distros will move to systemd anyway, even Debian I bet. They already moved to stupid Upstart (like RHEL 6 IIRC). jirib
Re: upstream vendors and why they can be really harmful
I hear you on this, thinking about it I'd like to ask you what would be a solution to this rather recurrent issue/problem we're facing from the Linux side of the spectrum? What would be a solution or a framework that could somehow negate most of the effects of this particular problem?. I grew up tired as well from this bs that clearly affects OpenBSD appeal to the masses. But, in life I've learned to make decisions, and no decision is free and I just pay the bill and live peacefully away from bullshit and bad software. On Tue, Nov 6, 2012 at 1:38 PM, Marc Espie es...@nerim.net wrote: Basically, we have a pattern, mostly observed with kde (and a bit with gnome) which is really harmful for us. Those vendors say we're not in the distribution business, distribution problems will be handled by OS vendors. We can break compatibility to advance, and not think about it, this is not a problem. This is a mindset we need to fight, and this has to be a grass-roots movement. The main effect of THAT attitude is to *HURT* the opensource community, big time. It's as harmful as the patent portfolio of big business. Basically, it precludes smaller players from playing on a level field. As soon as you're different enough (and that's mostly NOT linux these days), you can't keep up. Those distribution problems are LARGE. They occupy a few people in our team FULLTIME with respect to gnome, they're the reason we still DON'T have a full kde4 in our tree (hopefully to be addressed shortly), and they're the reason why sometimes we do drop old stuff (like killing gtk+1, and people really wanting to kill some gtk2/qt3 stuff). It takes a lot of manpower to address complex distribution issues. If you don't have tens of people, it becomes more and more of a losing battle, actually... It's also quickly turning Posix and Unix into a travesty: either you have the linux goodies, or you don't. And if you don't, you can forget anything modern... in some cases, you even have some people, who are PAID by some vendors, agressively pushing GRATUITOUS, non compatible changes. I won't say names, but you guys can fill the blanks in. I'm pretty sure there's a lot of good intention behind the progress in recent desktops. But this is turning the field of OS distributions into a wasteland. Either you're a modern linux with pulseaudio and pam and systemd, or you're dying. So much for the pionneer spirit of opensource, where you were free to innovate and do cool things, and more or less have interesting software able to run on your machine...
dc(1) exp improvements
Hi,
And here's a diff to repair ^, whcih now produces correct results for
things like
(dc)0.1 _1 ^p
or
(bc)0.1 ^ -1
The diff is against very current, so beware.
Please test. I have some regress test updates for dc as well. t9 turns
out to be a wrong test (computation of 2.1 ^ 500). That is fixed with
this diff as well.
-Otto
Index: bcode.c
===
RCS file: /cvs/src/usr.bin/dc/bcode.c,v
retrieving revision 1.44
diff -u -p -r1.44 bcode.c
--- bcode.c 6 Nov 2012 16:00:05 - 1.44
+++ bcode.c 6 Nov 2012 19:42:07 -
@@ -257,6 +257,12 @@ init_bmachine(bool extended_registers)
(void)signal(SIGINT, sighandler);
}
+u_int
+bmachine_scale(void)
+{
+ return bmachine.scale;
+}
+
/* Reset the things needed before processing a (new) file */
void
reset_bmachine(struct source *src)
@@ -991,7 +997,7 @@ bsub(void)
}
void
-bmul_number(struct number *r, struct number *a, struct number *b)
+bmul_number(struct number *r, struct number *a, struct number *b, u_int scale)
{
BN_CTX *ctx;
@@ -1007,7 +1013,7 @@ bmul_number(struct number *r, struct num
if (rscale bmachine.scale rscale ascale rscale bscale) {
r-scale = rscale;
- normalize(r, max(bmachine.scale, max(ascale, bscale)));
+ normalize(r, max(scale, max(ascale, bscale)));
} else
r-scale = rscale;
}
@@ -1029,7 +1035,7 @@ bmul(void)
}
r = new_number();
- bmul_number(r, a, b);
+ bmul_number(r, a, b, bmachine.scale);
push_number(r);
free_number(a);
@@ -1160,7 +1166,7 @@ bexp(void)
struct number *a, *p;
struct number *r;
boolneg;
- u_int scale;
+ u_int rscale;
p = pop_number();
if (p == NULL) {
@@ -1191,7 +1197,7 @@ bexp(void)
if (BN_is_negative(p-number)) {
neg = true;
negate(p);
- scale = bmachine.scale;
+ rscale = bmachine.scale;
} else {
/* Posix bc says min(a.scale * b, max(a.scale, scale) */
u_long b;
@@ -1199,30 +1205,35 @@ bexp(void)
b = BN_get_word(p-number);
m = max(a-scale, bmachine.scale);
- scale = a-scale * (u_int)b;
- if (scale m || (a-scale 0 (b == BN_MASK2 ||
+ rscale = a-scale * (u_int)b;
+ if (rscale m || (a-scale 0 (b == BN_MASK2 ||
b UINT_MAX)))
- scale = m;
+ rscale = m;
}
if (BN_is_zero(p-number)) {
r = new_number();
bn_check(BN_one(r-number));
- normalize(r, scale);
+ normalize(r, rscale);
} else {
+ u_int scale, ascale = a-scale;
while (!BN_is_bit_set(p-number, 0)) {
- bmul_number(a, a, a);
+ ascale *= 2;
+ bmul_number(a, a, a, ascale);
bn_check(BN_rshift1(p-number, p-number));
}
r = dup_number(a);
- normalize(r, scale);
bn_check(BN_rshift1(p-number, p-number));
+ scale = ascale;
while (!BN_is_zero(p-number)) {
- bmul_number(a, a, a);
- if (BN_is_bit_set(p-number, 0))
- bmul_number(r, r, a);
+ ascale *= 2;
+ bmul_number(a, a, a, ascale);
+ if (BN_is_bit_set(p-number, 0)) {
+ scale += ascale;
+ bmul_number(r, r, a, scale);
+ }
bn_check(BN_rshift1(p-number, p-number));
}
@@ -1235,8 +1246,7 @@ bexp(void)
bn_check(BN_one(one));
ctx = BN_CTX_new();
bn_checkp(ctx);
- scale_number(one, r-scale + scale);
- normalize(r, scale);
+ scale_number(one, r-scale + rscale);
if (BN_is_zero(r-number))
warnx(divide by zero);
@@ -1245,8 +1255,9 @@ bexp(void)
r-number, ctx));
BN_free(one);
BN_CTX_free(ctx);
+ r-scale = rscale;
} else
- normalize(r, scale);
+ normalize(r, rscale);
}
push_number(r);
free_number(a);
Index: bcode.h
===
RCS file: /cvs/src/usr.bin/dc/bcode.h,v
retrieving revision 1.6
diff -u -p -r1.6 bcode.h
--- bcode.h 6 Nov 2012 16:00:05
Re: em(4): enable TCP/UDP checksum offload
For people who are testing checksum-offload-enabling diffs, it would help if you could say what sort of things have tested. Things like fragments/NFS are far more likely to exercise bugs in the hardware than standard web browsing.
Re: upstream vendors and why they can be really harmful
On Tue, Nov 06, 2012 at 08:42:48PM +0100, TAKRIZ wrote: I hear you on this, thinking about it I'd like to ask you what would be a solution to this rather recurrent issue/problem we're facing from the Linux side of the spectrum? What would be a solution or a framework that could somehow negate most of the effects of this particular problem?. I grew up tired as well from this bs that clearly affects OpenBSD appeal to the masses. But, in life I've learned to make decisions, and no decision is free and I just pay the bill and live peacefully away from bullshit and bad software. Maybe I should be MORE explicit about this. I don't have ANY KIND OF SOLUTION. I know what the problem is (I think), and I don't think I'm part of the solution. I think that people talking about it, asking gnome/kde/whatever to solve the distribution issue (partly) might be the solution. Heck, the problem *in the first place* is that OpenBSD is *below some critical mass* developer-wise to *really* affect that state of being. Now, you are asking *me*, as an overbooked, overwhelmed developer, to also provide a solution for that problem ? Come on, that's something that doesn't require any of the skills I have. You guys get off your collective asses and start figuring out an actual solution. There's no need to directly involve me. Heck, there's probably little need to involve any of the current developers ! who are *all* vastly busy. It's very simple: figure out a way to get more developers involved in OpenBSD, or figure out a way to talk to gnome/kde/whatever so that we get a better chance at cooperating with them...
Re: upstream vendors and why they can be really harmful
On Tue, 6 Nov 2012 21:39:42 +0100 Marc Espie es...@nerim.net wrote: I don't have ANY KIND OF SOLUTION. Certainly couldn't for that general problem without likely being the problem. As I've said before I'm not a Gnome fan and far from a Gnome 3 fan however the reason udisks dropped many gnome features like automount for over 6 months was due to RedHats drive for multiseat which actually 99% of Linux care nothing about and perhaps has something to do with all the feature bloat and dependency issues in order to get the support from the community. Lennart has said (in a slghtly reasonable manner for once) in the thread Antoine was involved in on Gnomes list that multiseat is a large part of the portability issue. As Gnome already has dilemmas affecting user experience possibly wanting splits into. Touchscreen mode Touchscreen and mouse mode mouse mode Perhaps an Enterprise multiseat mode as well as these would atleast in my opinion and pointed out in this heise article perhaps save their bacon as the main linux desktop. http://www.h-online.com/open/features/GNOME-from-abyss-to-common-ground-1667974.html I can't see OpenBSD caring one bit about losing out on Enterprise mode ;-)
Re: dc(1) exp improvements
On Tue, Nov 6, 2012 at 3:27 PM, Otto Moerbeek o...@drijf.net wrote:
Hi,
And here's a diff to repair ^, whcih now produces correct results for
things like
(dc)0.1 _1 ^p
or
(bc)0.1 ^ -1
The diff is against very current, so beware.
i've lightly tested it against gnu bc and it works
i do have 2 small comments below
Please test. I have some regress test updates for dc as well. t9 turns
out to be a wrong test (computation of 2.1 ^ 500). That is fixed with
this diff as well.
-Otto
Index: bcode.c
===
RCS file: /cvs/src/usr.bin/dc/bcode.c,v
retrieving revision 1.44
diff -u -p -r1.44 bcode.c
--- bcode.c 6 Nov 2012 16:00:05 - 1.44
+++ bcode.c 6 Nov 2012 19:42:07 -
@@ -257,6 +257,12 @@ init_bmachine(bool extended_registers)
(void)signal(SIGINT, sighandler);
}
+u_int
+bmachine_scale(void)
+{
+ return bmachine.scale;
+}
+
/* Reset the things needed before processing a (new) file */
void
reset_bmachine(struct source *src)
@@ -991,7 +997,7 @@ bsub(void)
}
void
-bmul_number(struct number *r, struct number *a, struct number *b)
+bmul_number(struct number *r, struct number *a, struct number *b, u_int
scale)
{
BN_CTX *ctx;
@@ -1007,7 +1013,7 @@ bmul_number(struct number *r, struct num
if (rscale bmachine.scale rscale ascale rscale bscale) {
r-scale = rscale;
- normalize(r, max(bmachine.scale, max(ascale, bscale)));
+ normalize(r, max(scale, max(ascale, bscale)));
} else
r-scale = rscale;
the function unconditionally sets r-scale to rscale, but the
operation is duplicated across `if' bodies. interpreting a diff for
the function is difficult because the intent is unclear
}
@@ -1029,7 +1035,7 @@ bmul(void)
}
r = new_number();
- bmul_number(r, a, b);
+ bmul_number(r, a, b, bmachine.scale);
push_number(r);
free_number(a);
@@ -1160,7 +1166,7 @@ bexp(void)
struct number *a, *p;
struct number *r;
boolneg;
- u_int scale;
+ u_int rscale;
p = pop_number();
if (p == NULL) {
@@ -1191,7 +1197,7 @@ bexp(void)
if (BN_is_negative(p-number)) {
neg = true;
negate(p);
- scale = bmachine.scale;
+ rscale = bmachine.scale;
} else {
/* Posix bc says min(a.scale * b, max(a.scale, scale) */
u_long b;
@@ -1199,30 +1205,35 @@ bexp(void)
b = BN_get_word(p-number);
m = max(a-scale, bmachine.scale);
- scale = a-scale * (u_int)b;
- if (scale m || (a-scale 0 (b == BN_MASK2 ||
+ rscale = a-scale * (u_int)b;
+ if (rscale m || (a-scale 0 (b == BN_MASK2 ||
b UINT_MAX)))
- scale = m;
+ rscale = m;
}
if (BN_is_zero(p-number)) {
r = new_number();
bn_check(BN_one(r-number));
- normalize(r, scale);
+ normalize(r, rscale);
} else {
+ u_int scale, ascale = a-scale;
`scale' should be renamed for clarity to signify that it's an
accumulator for `ascale'. at its current state, not being prefixed by
a letter that is, `scale' looks more important than it is
Re: heads-up: on -current, -static may not be as static as you think
On 2012/11/05 13:57, Marc Espie wrote: This stuff is totally a moving target, it is probably going to change in the future. Note that there are very good reasons to prefer pie binaries in MOST cases, including for 'static' binaries... So, as far as the chroot way goes, the most correct fix is probably to provide ld.so along with your binaries... It would be good to have some guidance on what to do with these, a number of ports are affected. There are likely to be more, this is from a quick look over things using '-static' in patches or ports tree Makefiles. specific static flavours:- archivers/gtar archivers/star misc/screen shells/tcsh net/nslint, static flavour security/shash, static flavour I presume the above just need -fno-pie / -nopie (or zap the static flavour if there's no point; nslint doesn't seem useful for example, not sure about shash). gtar/star/screen/tcsh are obviously intended for a recovery environment and I think should not require ld.so. others due to chroot:- mail/femail mail/mini_sendmail net/icinga net/nagios www/fcgi-cgi devel/fossil sysutils/nut www/cgit www/haserl www/mimetex www/squid Any suggestions? We could have an always-update package containing a copy of ld.so that installs to /var/www/usr/libexec that these depend on, but if we make further changes to ld.so requiring something new from the kernel, it's going to get out of sync. Including /var/www/usr/libexec/ld.so in base would be safer but does not seem a particularly attractive option. Note that these are currently *broken* as packaged; existing users of the packages are unlikely to see the breakage, no libc bump since PIE (and in several of these cases no dependency on libc in the whole package anyway) so there won't have been reason for pkg_add to update them. However people installing these from scratch (or forcing an update) will have problems. some others known to use -static:- security/tempwatch security/cryptcat x11/wmii benchmarks/bonnie benchmarks/bytebench
[cwm] tab completion
I think this one is ready for wider testing.
How to use: hit tab in exec menu to complete the command (start
with / if you want something not in $PATH). When you're ready,
hit tab again. This will open file menu, which can be used to
complete file argument.
Completion works for other menus as well.
Index: calmwm.h
===
RCS file: /cvs/xenocara/app/cwm/calmwm.h,v
retrieving revision 1.155
diff -u -p -u -r1.155 calmwm.h
--- calmwm.h31 Oct 2012 22:06:24 - 1.155
+++ calmwm.h5 Nov 2012 22:20:42 -
@@ -73,6 +73,10 @@
#define CWM_RCYCLE 0x0002
#define CWM_INGROUP0x0004
+/* menu */
+#define CWM_MENU_DUMMY 0x0001
+#define CWM_MENU_FILE 0x0002
+
#define KBTOGROUP(X) ((X) - 1)
union arg {
@@ -260,7 +264,7 @@ TAILQ_HEAD(cmd_q, cmd);
struct menu {
TAILQ_ENTRY(menu)entry;
TAILQ_ENTRY(menu)resultentry;
-#define MENU_MAXENTRY 50
+#define MENU_MAXENTRY 200
char text[MENU_MAXENTRY + 1];
char print[MENU_MAXENTRY + 1];
void*ctx;
@@ -355,7 +359,11 @@ voidsearch_match_client(struct
menu_
char *);
voidsearch_match_exec(struct menu_q *, struct menu_q *,
char *);
+voidsearch_match_exec_path(struct menu_q *, struct menu_q
*,
+char *);
voidsearch_match_text(struct menu_q *, struct menu_q *,
+char *);
+voidsearch_match_path(struct menu_q *, struct menu_q *,
char *);
voidsearch_print_client(struct menu *, int);
Index: kbfunc.c
===
RCS file: /cvs/xenocara/app/cwm/kbfunc.c,v
retrieving revision 1.64
diff -u -p -u -r1.64 kbfunc.c
--- kbfunc.c31 Oct 2012 19:30:19 - 1.64
+++ kbfunc.c5 Nov 2012 22:20:42 -
@@ -298,8 +298,9 @@ kbfunc_exec(struct client_ctx *cc, union
}
xfree(path);
- if ((mi = menu_filter(sc, menuq, label, NULL, 1,
- search_match_exec, NULL)) != NULL) {
+ if ((mi = menu_filter(sc, menuq, label, NULL,
+ CWM_MENU_DUMMY | CWM_MENU_FILE,
+ search_match_exec_path, NULL)) != NULL) {
if (mi-text[0] == '\0')
goto out;
switch (cmd) {
@@ -376,7 +377,7 @@ kbfunc_ssh(struct client_ctx *cc, union
xfree(lbuf);
(void)fclose(fp);
- if ((mi = menu_filter(sc, menuq, ssh, NULL, 1,
+ if ((mi = menu_filter(sc, menuq, ssh, NULL, CWM_MENU_DUMMY,
search_match_exec, NULL)) != NULL) {
if (mi-text[0] == '\0')
goto out;
@@ -403,7 +404,7 @@ kbfunc_client_label(struct client_ctx *c
TAILQ_INIT(menuq);
/* dummy is set, so this will always return */
- mi = menu_filter(cc-sc, menuq, label, cc-label, 1,
+ mi = menu_filter(cc-sc, menuq, label, cc-label, CWM_MENU_DUMMY,
search_match_text, NULL);
if (!mi-abort) {
Index: menu.c
===
RCS file: /cvs/xenocara/app/cwm/menu.c,v
retrieving revision 1.41
diff -u -p -u -r1.41 menu.c
--- menu.c 31 Oct 2012 19:30:19 - 1.41
+++ menu.c 5 Nov 2012 22:20:42 -
@@ -28,6 +28,7 @@
#include string.h
#include stdio.h
#include unistd.h
+#include ctype.h
#include calmwm.h
@@ -37,10 +38,11 @@
enum ctltype {
CTL_NONE = -1,
CTL_ERASEONE = 0, CTL_WIPE, CTL_UP, CTL_DOWN, CTL_RETURN,
- CTL_ABORT, CTL_ALL
+ CTL_TAB, CTL_ABORT, CTL_ALL
};
struct menu_ctx {
+ struct screen_ctx *sc;
char searchstr[MENU_MAXENTRY + 1];
char dispstr[MENU_MAXENTRY*2 + 1];
char promptstr[MENU_MAXENTRY + 1];
@@ -54,6 +56,7 @@ struct menu_ctx {
int height;
int width;
int num;
+ int flags;
int x;
int y;
void (*match)(struct menu_q *, struct menu_q *, char *);
@@ -93,7 +96,7 @@ menu_init(struct screen_ctx *sc)
struct menu *
menu_filter(struct screen_ctx *sc, struct menu_q *menuq, char *prompt,
-char *initial, int dummy,
+char *initial, int flags,
void (*match)(struct menu_q *, struct menu_q *, char *),
void (*print)(struct menu *, int))
{
@@ -114,6 +117,8 @@ menu_filter(struct screen_ctx *sc, struc
xsave = mc.x;
ysave = mc.y;
+ mc.sc = sc;
+ mc.flags = flags;
if (prompt == NULL) {
evmask = MENUMASK;
mc.promptstr[0] =
Re: upstream vendors and why they can be really harmful
On Tue, Nov 06, 2012 at 01:38:32PM +0100, Marc Espie wrote: It's also quickly turning Posix and Unix into a travesty: either you have the linux goodies, or you don't. And if you don't, you can forget anything modern... This IS the main problem.
Re: upstream vendors and why they can be really harmful
On Tue, 6 Nov 2012 13:38:32 +0100 Marc Espie es...@nerim.net wrote: Basically, we have a pattern, mostly observed with kde (and a bit with gnome) which is really harmful for us. They occupy a few people in our team FULLTIME with respect to gnome, they're the reason we still DON'T have a full kde4 in our tree (hopefully to be addressed shortly), and they're the reason why sometimes we do drop old stuff (like killing gtk+1, and people really wanting to kill some gtk2/qt3 stuff). It's also quickly turning Posix and Unix into a travesty: either you have the linux goodies, or you don't. And if you don't, you can forget anything modern... Not to disparage the hard work by Antoine and others on Gnome and KDE, but if upstream are going to entwine their code with non-standard OSs, then why bother with them? If everyone but the mainstream Linux distros dropped their projects, it seems a more likely way of getting through to the upstream developers than joining their project or sending them emails. I use Joe's Window Manager, it compiles in less than a minute straight from the sources with no patching or tweaking. I don't have semi-transparent windowbars and I had to make a couple of tweaks so I could hear a beep when I get an IM, apart from that, what can a modern window manager do that is worth the some porter's pain (and extra 10-20% cpu consumption to run) anyway? Stuff like X is a different matter, if upstream must be battled, I would say send the troops to defend what is hard to do without, not what is easy to do without. Brett.
Re: upstream vendors and why they can be really harmful
Basically, we have a pattern, mostly observed with kde (and a bit with gnome) which is really harmful for us. They occupy a few people in our team FULLTIME with respect to gnome, they're the reason we still DON'T have a full kde4 in our tree (hopefully to be addressed shortly), and they're the reason why sometimes we do drop old stuff (like killing gtk+1, and people really wanting to kill some gtk2/qt3 stuff). It's also quickly turning Posix and Unix into a travesty: either you have the linux goodies, or you don't. And if you don't, you can forget anything modern... Not to disparage the hard work by Antoine and others on Gnome and KDE, but if upstream are going to entwine their code with non-standard OSs, then why bother with them? If everyone but the mainstream Linux distros dropped their projects, it seems a more likely way of getting through to the upstream developers than joining their project or sending them emails. eventually they get the message but sometimes its too late. I use Joe's Window Manager, it compiles in less than a minute straight from the sources with no patching or tweaking. I don't have semi-transparent windowbars and I had to make a couple of tweaks so I could hear a beep when I get an IM, apart from that, what can a modern window manager do that is worth the some porter's pain (and extra 10-20% cpu consumption to run) anyway? Stuff like X is a different matter, if upstream must be battled, I would say send the troops to defend what is hard to do without, not what is easy to do without. I care about some things in kde4 like kdevelop/kate, educational apps for kids (very few mainstream distros bother for children), for qt4/5 the ability to write a single code for mobile + desktop amongst some things. There are some things in the big WMs which are missing in JWM :-) Probably other guys have different motivations.
Re: heads-up: on -current, -static may not be as static as you think
On Tue, 6 Nov 2012 21:49:12 +, Stuart Henderson wrote: On 2012/11/05 13:57, Marc Espie wrote: This stuff is totally a moving target, it is probably going to change in the future. Note that there are very good reasons to prefer pie binaries in MOST cases, including for 'static' binaries... So, as far as the chroot way goes, the most correct fix is probably to provide ld.so along with your binaries... It would be good to have some guidance on what to do with these, a number of ports are affected. There are likely to be more, this is from a quick look over things using '-static' in patches or ports tree Makefiles. specific static flavours:- archivers/gtar archivers/star misc/screen shells/tcsh net/nslint, static flavour security/shash, static flavour I presume the above just need -fno-pie / -nopie (or zap the static flavour if there's no point; nslint doesn't seem useful for example, not sure about shash). gtar/star/screen/tcsh are obviously intended for a recovery environment and I think should not require ld.so. ack. others due to chroot:- mail/femail mail/mini_sendmail net/icinga net/nagios www/fcgi-cgi devel/fossil sysutils/nut www/cgit www/haserl www/mimetex www/squid Any suggestions? We could have an always-update package containing a copy of ld.so that installs to /var/www/usr/libexec that these depend on, but if we make further changes to ld.so requiring something new from the kernel, it's going to get out of sync. Including /var/www/usr/libexec/ld.so in base would be safer but does not seem a particularly attractive option. My vote is to have them use -fno-pie/-nopie as well. Note that these are currently *broken* as packaged; existing users of the packages are unlikely to see the breakage, no libc bump since PIE (and in several of these cases no dependency on libc in the whole package anyway) so there won't have been reason for pkg_add to update them. However people installing these from scratch (or forcing an update) will have problems. some others known to use -static:- security/tempwatch security/cryptcat x11/wmii benchmarks/bonnie benchmarks/bytebench
Re: [cwm] tab completion
* Alexander Polakov p...@sdf.org [121107 02:20]:
I think this one is ready for wider testing.
How to use: hit tab in exec menu to complete the command (start
with / if you want something not in $PATH). When you're ready,
hit tab again. This will open file menu, which can be used to
complete file argument.
Completion works for other menus as well.
Oops, sorry, I sent the wrong diff (previous revision).
Index: calmwm.h
===
RCS file: /cvs/xenocara/app/cwm/calmwm.h,v
retrieving revision 1.155
diff -u -p -u -r1.155 calmwm.h
--- calmwm.h31 Oct 2012 22:06:24 - 1.155
+++ calmwm.h7 Nov 2012 01:06:13 -
@@ -73,6 +73,10 @@
#define CWM_RCYCLE 0x0002
#define CWM_INGROUP0x0004
+/* menu */
+#define CWM_MENU_DUMMY 0x0001
+#define CWM_MENU_FILE 0x0002
+
#define KBTOGROUP(X) ((X) - 1)
union arg {
@@ -260,7 +264,7 @@ TAILQ_HEAD(cmd_q, cmd);
struct menu {
TAILQ_ENTRY(menu)entry;
TAILQ_ENTRY(menu)resultentry;
-#define MENU_MAXENTRY 50
+#define MENU_MAXENTRY 200
char text[MENU_MAXENTRY + 1];
char print[MENU_MAXENTRY + 1];
void*ctx;
@@ -354,6 +358,10 @@ voidgroup_update_names(struct
screen
voidsearch_match_client(struct menu_q *, struct menu_q *,
char *);
voidsearch_match_exec(struct menu_q *, struct menu_q *,
+char *);
+voidsearch_match_exec_path(struct menu_q *, struct menu_q
*,
+char *);
+voidsearch_match_path_any(struct menu_q *, struct menu_q *,
char *);
voidsearch_match_text(struct menu_q *, struct menu_q *,
char *);
Index: kbfunc.c
===
RCS file: /cvs/xenocara/app/cwm/kbfunc.c,v
retrieving revision 1.64
diff -u -p -u -r1.64 kbfunc.c
--- kbfunc.c31 Oct 2012 19:30:19 - 1.64
+++ kbfunc.c7 Nov 2012 01:06:13 -
@@ -298,8 +298,9 @@ kbfunc_exec(struct client_ctx *cc, union
}
xfree(path);
- if ((mi = menu_filter(sc, menuq, label, NULL, 1,
- search_match_exec, NULL)) != NULL) {
+ if ((mi = menu_filter(sc, menuq, label, NULL,
+ CWM_MENU_DUMMY | CWM_MENU_FILE,
+ search_match_exec_path, NULL)) != NULL) {
if (mi-text[0] == '\0')
goto out;
switch (cmd) {
@@ -376,7 +377,7 @@ kbfunc_ssh(struct client_ctx *cc, union
xfree(lbuf);
(void)fclose(fp);
- if ((mi = menu_filter(sc, menuq, ssh, NULL, 1,
+ if ((mi = menu_filter(sc, menuq, ssh, NULL, CWM_MENU_DUMMY,
search_match_exec, NULL)) != NULL) {
if (mi-text[0] == '\0')
goto out;
@@ -403,7 +404,7 @@ kbfunc_client_label(struct client_ctx *c
TAILQ_INIT(menuq);
/* dummy is set, so this will always return */
- mi = menu_filter(cc-sc, menuq, label, cc-label, 1,
+ mi = menu_filter(cc-sc, menuq, label, cc-label, CWM_MENU_DUMMY,
search_match_text, NULL);
if (!mi-abort) {
Index: menu.c
===
RCS file: /cvs/xenocara/app/cwm/menu.c,v
retrieving revision 1.41
diff -u -p -u -r1.41 menu.c
--- menu.c 31 Oct 2012 19:30:19 - 1.41
+++ menu.c 7 Nov 2012 01:06:13 -
@@ -28,6 +28,7 @@
#include string.h
#include stdio.h
#include unistd.h
+#include ctype.h
#include calmwm.h
@@ -37,10 +38,11 @@
enum ctltype {
CTL_NONE = -1,
CTL_ERASEONE = 0, CTL_WIPE, CTL_UP, CTL_DOWN, CTL_RETURN,
- CTL_ABORT, CTL_ALL
+ CTL_TAB, CTL_ABORT, CTL_ALL
};
struct menu_ctx {
+ struct screen_ctx *sc;
char searchstr[MENU_MAXENTRY + 1];
char dispstr[MENU_MAXENTRY*2 + 1];
char promptstr[MENU_MAXENTRY + 1];
@@ -54,6 +56,7 @@ struct menu_ctx {
int height;
int width;
int num;
+ int flags;
int x;
int y;
void (*match)(struct menu_q *, struct menu_q *, char *);
@@ -93,7 +96,7 @@ menu_init(struct screen_ctx *sc)
struct menu *
menu_filter(struct screen_ctx *sc, struct menu_q *menuq, char *prompt,
-char *initial, int dummy,
+char *initial, int flags,
void (*match)(struct menu_q *, struct menu_q *, char *),
void (*print)(struct menu *, int))
{
@@ -114,6 +117,8 @@ menu_filter(struct screen_ctx *sc, struc
xsave = mc.x;
ysave = mc.y;
+ mc.sc =
Re: dc(1) exp improvements
On Tue, Nov 06, 2012 at 04:57:20PM -0430, Andres Perera wrote:
On Tue, Nov 6, 2012 at 3:27 PM, Otto Moerbeek o...@drijf.net wrote:
Hi,
And here's a diff to repair ^, whcih now produces correct results for
things like
(dc)0.1 _1 ^p
or
(bc)0.1 ^ -1
The diff is against very current, so beware.
i've lightly tested it against gnu bc and it works
i do have 2 small comments below
Fair enough. New diff.
-Otto
Index: bcode.c
===
RCS file: /cvs/src/usr.bin/dc/bcode.c,v
retrieving revision 1.44
diff -u -p -r1.44 bcode.c
--- bcode.c 6 Nov 2012 16:00:05 - 1.44
+++ bcode.c 7 Nov 2012 06:45:52 -
@@ -257,6 +257,12 @@ init_bmachine(bool extended_registers)
(void)signal(SIGINT, sighandler);
}
+u_int
+bmachine_scale(void)
+{
+ return bmachine.scale;
+}
+
/* Reset the things needed before processing a (new) file */
void
reset_bmachine(struct source *src)
@@ -991,7 +997,7 @@ bsub(void)
}
void
-bmul_number(struct number *r, struct number *a, struct number *b)
+bmul_number(struct number *r, struct number *a, struct number *b, u_int scale)
{
BN_CTX *ctx;
@@ -1005,11 +1011,9 @@ bmul_number(struct number *r, struct num
bn_check(BN_mul(r-number, a-number, b-number, ctx));
BN_CTX_free(ctx);
- if (rscale bmachine.scale rscale ascale rscale bscale) {
- r-scale = rscale;
- normalize(r, max(bmachine.scale, max(ascale, bscale)));
- } else
- r-scale = rscale;
+ r-scale = rscale;
+ if (rscale bmachine.scale rscale ascale rscale bscale)
+ normalize(r, max(scale, max(ascale, bscale)));
}
static void
@@ -1029,7 +1033,7 @@ bmul(void)
}
r = new_number();
- bmul_number(r, a, b);
+ bmul_number(r, a, b, bmachine.scale);
push_number(r);
free_number(a);
@@ -1160,7 +1164,7 @@ bexp(void)
struct number *a, *p;
struct number *r;
boolneg;
- u_int scale;
+ u_int rscale;
p = pop_number();
if (p == NULL) {
@@ -1191,7 +1195,7 @@ bexp(void)
if (BN_is_negative(p-number)) {
neg = true;
negate(p);
- scale = bmachine.scale;
+ rscale = bmachine.scale;
} else {
/* Posix bc says min(a.scale * b, max(a.scale, scale) */
u_long b;
@@ -1199,30 +1203,37 @@ bexp(void)
b = BN_get_word(p-number);
m = max(a-scale, bmachine.scale);
- scale = a-scale * (u_int)b;
- if (scale m || (a-scale 0 (b == BN_MASK2 ||
+ rscale = a-scale * (u_int)b;
+ if (rscale m || (a-scale 0 (b == BN_MASK2 ||
b UINT_MAX)))
- scale = m;
+ rscale = m;
}
if (BN_is_zero(p-number)) {
r = new_number();
bn_check(BN_one(r-number));
- normalize(r, scale);
+ normalize(r, rscale);
} else {
+ u_int ascale, mscale;
+
+ ascale = a-scale;
while (!BN_is_bit_set(p-number, 0)) {
- bmul_number(a, a, a);
+ ascale *= 2;
+ bmul_number(a, a, a, ascale);
bn_check(BN_rshift1(p-number, p-number));
}
r = dup_number(a);
- normalize(r, scale);
bn_check(BN_rshift1(p-number, p-number));
+ mscale = ascale;
while (!BN_is_zero(p-number)) {
- bmul_number(a, a, a);
- if (BN_is_bit_set(p-number, 0))
- bmul_number(r, r, a);
+ ascale *= 2;
+ bmul_number(a, a, a, ascale);
+ if (BN_is_bit_set(p-number, 0)) {
+ mscale += ascale;
+ bmul_number(r, r, a, mscale);
+ }
bn_check(BN_rshift1(p-number, p-number));
}
@@ -1235,8 +1246,7 @@ bexp(void)
bn_check(BN_one(one));
ctx = BN_CTX_new();
bn_checkp(ctx);
- scale_number(one, r-scale + scale);
- normalize(r, scale);
+ scale_number(one, r-scale + rscale);
if (BN_is_zero(r-number))
warnx(divide by zero);
@@ -1245,8 +1255,9 @@ bexp(void)
r-number, ctx));
BN_free(one);
BN_CTX_free(ctx);
+ r-scale = rscale;
} else
-
Re: upstream vendors and why they can be really harmful
07.11.2012 2:06 полÑзоваÑÐµÐ»Ñ Brett brett.ma...@gmx.com напиÑал: On Tue, 6 Nov 2012 13:38:32 +0100 Marc Espie es...@nerim.net wrote: Basically, we have a pattern, mostly observed with kde (and a bit with gnome) which is really harmful for us. They occupy a few people in our team FULLTIME with respect to gnome, they're the reason we still DON'T have a full kde4 in our tree (hopefully to be addressed shortly), and they're the reason why sometimes we do drop old stuff (like killing gtk+1, and people really wanting to kill some gtk2/qt3 stuff). It's also quickly turning Posix and Unix into a travesty: either you have the linux goodies, or you don't. And if you don't, you can forget anything modern... Not to disparage the hard work by Antoine and others on Gnome and KDE, but if upstream are going to entwine their code with non-standard OSs, then why bother with them? If everyone but the mainstream Linux distros dropped their projects, it seems a more likely way of getting through to the upstream developers than joining their project or sending them emails. I use Joe's Window Manager, it compiles in less than a minute straight from the sources with no patching or tweaking. I don't have semi-transparent windowbars and I had to make a couple of tweaks so I could hear a beep when I get an IM, apart from that, what can a modern window manager do that is worth the some porter's pain (and extra 10-20% cpu consumption to run) anyway? Stuff like X is a different matter, if upstream must be battled, I would say send the troops to defend what is hard to do without, not what is easy to do without. I can speak only about KDE and OpenBSD. Yes, KDE is driven mostly by Ubuntu and Fedora users. SUSE and Arch are pocking around too. FreeBSD have a whole team (4 members last time I checked) working on bringing fresh KDE 4. We have two, working part-time and semi-official. But we're in better state than Windows port already. Yes, KDE doesn't care if some functionality isn't available on other platforms. But they are at least open enough. Some time ago I've sent a patch to Konsole developers, enabling process information gathering on OpenBSD. Upstream developer tried hard to build testing environment for a few days without any request from me, and, after predictable fail, :) still committed the code. kdelibs developers accept patches happily too... Of course, there ARE developers that say Linux or losers, but you can ignore them safely, there are many other, more adequate, persons. KDE is just... huge. There is a plenty of work. But even me, not-so-knowledgeable-man, could deal with it - thanks to some decisions and actions both KDE and OpenBSD developers made and continue making. And that doesn't mean that KDE 4 wasn't usable at all until 4.6, on any platform - including Linux. :)
Re: upstream vendors and why they can be really harmful
On Wed, Nov 07, 2012 at 08:58:55AM +1100, Brett wrote: Not to disparage the hard work by Antoine and others on Gnome and KDE, but if upstream are going to entwine their code with non-standard OSs, then why bother with them? That _is_ precisely the question I asked on GNOME lists. I'm not ranting about the fact that they started requiring systemd features, it's their choice after all. Whining after it's done is pretty much useless. If you want a project you like to go in a direction that you think is better, then you need to get involved way sooner in the development process. Most of the time people rant about GNOME's direction but are not even using GNOME themselves or don't like it anyway. My real concern was to know where this was going exactly so that I could make a decision whether it would still make sense to keep working on it (which is a huge work, trust me) or not. It's not like it's the only Desktop available out there and I don't think it particularly hurts us if it were to disapear from ports; but if other more important projects (for us) follow the same direction, then it is getting problematic. I use Joe's Window Manager, it compiles in less than a minute straight from the sources with no patching or tweaking. I don't have semi-transparent windowbars and I had to make a couple of tweaks so I could hear a beep when I get an IM, apart from that, what can a modern window manager do that is worth the some porter's pain (and extra 10-20% cpu consumption to run) anyway? My cpu is idle when I'm not doing anything under GNOME. There are many reasons why a fully integrated point-and-click Desktop is attractive to some people, but this is not the topic here. Stuff like X is a different matter, if upstream must be battled, I would say send the troops to defend what is hard to do without, not what is easy to do without. Then gather your troups and go fight or provide code, because between KMS and llvmpipe we are already way way behind... Out of the 10 machines I have at home, only 1 has a fully supported X driver. The main issue is that the BSD community is very small and as espie@ mentionned, developers already have no time on their hand so it's hard to get yourself heard. Let's be pragmatic, 99% of the work is made by Linux people with no !linux developer/user being involved; why would they bother about portability if no one around challenges them? As a member of the GNOME project I can tell you that not everyone there is deaf or incompetent, and if you come with proper arguments (and code) they will be more than happy to include it or change the way they do things to accomodate to standards. Lennart is a different matter, he made it clear he doesn't care about the rest of the ecosystem. But he is just one guy and his lobbying works also because no one else is here to challenge him. It's one thing to rant on mailing list and blobs... -- Antoine
Re: em(4): enable TCP/UDP checksum offload
In my case, it is a CARP backup(master will be upgraded soon) rolling ospf on top of gre on top of ipsec, running npppd, and daily NAT/RDR for about 100 clients. On 6 nov 2012, at 21:31, Stuart Henderson s...@spacehopper.org wrote: For people who are testing checksum-offload-enabling diffs, it would help if you could say what sort of things have tested. Things like fragments/NFS are far more likely to exercise bugs in the hardware than standard web browsing.
