Re: Ethernert drivers (MI) and muticast filters
On 11/11/13(Mon) 11:31, Martin Pieuchot wrote:
I'm still looking for tests/oks for the driver changed in the diff
below.
Here's what I said on Oct 17th:
Diff below converts the remaining drivers in our tree that still compare
the low and high value of their Ethernet multicast ranges to set the
IFF_ALLMULTI flag to use ac-ac_multirangecnt instead. This should
not change the behavior of any driver.
The goal if this diff is to stop using the ``enm_addrhi'' field of
the ether_multi structure to be able to modify our multicast address
representation in a backward compatible way (without modifying more
drivers than that!).
Updated diff, rebased on top of recent changes:
Index: dev/ic/aic6915.c
===
RCS file: /cvs/src/sys/dev/ic/aic6915.c,v
retrieving revision 1.10
diff -u -p -r1.10 aic6915.c
--- dev/ic/aic6915.c7 Aug 2013 01:06:27 - 1.10
+++ dev/ic/aic6915.c16 Oct 2013 13:28:53 -
@@ -1341,6 +1341,9 @@ sf_set_filter(struct sf_softc *sc)
*/
sf_set_filter_perfect(sc, 0, LLADDR(ifp-if_sadl));
+ if (ac-ac_multirangecnt 0)
+ goto allmulti;
+
/*
* Now set the hash bits for each multicast address in our
* list.
@@ -1349,17 +1352,6 @@ sf_set_filter(struct sf_softc *sc)
if (enm == NULL)
goto done;
while (enm != NULL) {
- if (memcmp(enm-enm_addrlo, enm-enm_addrhi, ETHER_ADDR_LEN)) {
- /*
-* We must listen to a range of multicast addresses.
-* For now, just accept all multicasts, rather than
-* trying to set only those filter bits needed to match
-* the range. (At this time, the only use of address
-* ranges is for IP multicast routing, for which the
-* range is big enough to require all bits set.)
-*/
- goto allmulti;
- }
sf_set_filter_hash(sc, enm-enm_addrlo);
ETHER_NEXT_MULTI(step, enm);
}
Index: dev/ic/ath.c
===
RCS file: /cvs/src/sys/dev/ic/ath.c,v
retrieving revision 1.96
diff -u -p -r1.96 ath.c
--- dev/ic/ath.c17 Oct 2012 00:59:57 - 1.96
+++ dev/ic/ath.c16 Oct 2013 13:28:53 -
@@ -1148,18 +1148,20 @@ ath_mcastfilter_accum(caddr_t dl, u_int3
void
ath_mcastfilter_compute(struct ath_softc *sc, u_int32_t (*mfilt)[2])
{
+ struct arpcom *ac = sc-sc_ic.ic_ac;
struct ifnet *ifp = sc-sc_ic.ic_if;
struct ether_multi *enm;
struct ether_multistep estep;
- ETHER_FIRST_MULTI(estep, sc-sc_ic.ic_ac, enm);
- while (enm != NULL) {
+ if (ac-ac_multirangecnt 0) {
/* XXX Punt on ranges. */
- if (!IEEE80211_ADDR_EQ(enm-enm_addrlo, enm-enm_addrhi)) {
- (*mfilt)[0] = (*mfilt)[1] = ~((u_int32_t)0);
- ifp-if_flags |= IFF_ALLMULTI;
- return;
- }
+ (*mfilt)[0] = (*mfilt)[1] = ~((u_int32_t)0);
+ ifp-if_flags |= IFF_ALLMULTI;
+ return;
+ }
+
+ ETHER_FIRST_MULTI(estep, ac, enm);
+ while (enm != NULL) {
ath_mcastfilter_accum(enm-enm_addrlo, mfilt);
ETHER_NEXT_MULTI(estep, enm);
}
Index: dev/ic/athn.c
===
RCS file: /cvs/src/sys/dev/ic/athn.c,v
retrieving revision 1.78
diff -u -p -r1.78 athn.c
--- dev/ic/athn.c 15 Nov 2013 01:45:44 - 1.78
+++ dev/ic/athn.c 19 Nov 2013 09:06:29 -
@@ -2626,6 +2626,9 @@ athn_set_multi(struct athn_softc *sc)
uint32_t val, lo, hi;
uint8_t bit;
+ if (ac-ac_multirangecnt 0)
+ ifp-if_flags |= IFF_ALLMULTI;
+
if ((ifp-if_flags (IFF_ALLMULTI | IFF_PROMISC)) != 0) {
lo = hi = 0x;
goto done;
@@ -2633,11 +2636,6 @@ athn_set_multi(struct athn_softc *sc)
lo = hi = 0;
ETHER_FIRST_MULTI(step, ac, enm);
while (enm != NULL) {
- if (memcmp(enm-enm_addrlo, enm-enm_addrhi, 6) != 0) {
- ifp-if_flags |= IFF_ALLMULTI;
- lo = hi = 0x;
- goto done;
- }
addr = enm-enm_addrlo;
/* Calculate the XOR value of all eight 6-bit words. */
val = addr[0] | addr[1] 8 | addr[2] 16;
Index: dev/ic/atw.c
===
RCS file: /cvs/src/sys/dev/ic/atw.c,v
retrieving revision 1.77
diff -u -p -r1.77 atw.c
--- dev/ic/atw.c14 Nov 2013 12:30:39 - 1.77
+++ dev/ic/atw.c19 Nov 2013 09:06:29 -
@@ -2030,7
Re: Don't link multicast records to the first address
On 18/11/13(Mon) 12:54, Alexey E. Suslikov wrote:
Martin Pieuchot mpieuchot at nolizard.org writes:
at at -1803,8 +1651,12 at at in6_delmulti(struct in6_multi
*in6m)
snip
+ s = splsoftnet();
+ TAILQ_REMOVE(ifp-if_maddrlist, in6m-in6m_ifma, ifma_list);
+ splx(s);
+
free(in6m, M_IPMADDR);
}
splx(s);
this splx seems wrong.
Good catch! Here's and updated version, that comes with more spl love.
Index: net/if.c
===
RCS file: /home/ncvs/src/sys/net/if.c,v
retrieving revision 1.277
diff -u -p -r1.277 if.c
--- net/if.c19 Nov 2013 09:00:43 - 1.277
+++ net/if.c19 Nov 2013 10:07:24 -
@@ -437,8 +437,9 @@ if_attach(struct ifnet *ifp)
void
if_attach_common(struct ifnet *ifp)
{
-
TAILQ_INIT(ifp-if_addrlist);
+ TAILQ_INIT(ifp-if_maddrlist);
+
ifp-if_addrhooks = malloc(sizeof(*ifp-if_addrhooks),
M_TEMP, M_WAITOK);
TAILQ_INIT(ifp-if_addrhooks);
Index: net/if.h
===
RCS file: /home/ncvs/src/sys/net/if.h,v
retrieving revision 1.152
diff -u -p -r1.152 if.h
--- net/if.h9 Nov 2013 06:38:42 - 1.152
+++ net/if.h19 Nov 2013 10:07:24 -
@@ -262,6 +262,7 @@ struct ifnet { /* and the
entries */
TAILQ_ENTRY(ifnet) if_list; /* all struct ifnets are chained */
TAILQ_ENTRY(ifnet) if_txlist; /* list of ifnets ready to tx */
TAILQ_HEAD(, ifaddr) if_addrlist; /* linked list of addresses per if */
+ TAILQ_HEAD(, ifmaddr) if_maddrlist; /* list of multicast records */
TAILQ_HEAD(, ifg_list) if_groups; /* linked list of groups per if */
struct hook_desc_head *if_addrhooks; /* address change callbacks */
struct hook_desc_head *if_linkstatehooks; /* link change callbacks */
@@ -506,6 +507,16 @@ struct ifaddr_item {
struct ifaddr *ifai_ifa;
struct ifaddr_item *ifai_next;
u_intifai_rdomain;
+};
+
+/*
+ * Interface multicast address.
+ */
+struct ifmaddr {
+ struct sockaddr *ifma_addr; /* Protocol address */
+ struct ifnet*ifma_ifp; /* Back pointer to ifnet */
+ unsigned int ifma_refcnt; /* Count of references */
+ TAILQ_ENTRY(ifmaddr) ifma_list; /* Per-interface list */
};
/*
Index: netinet/igmp.c
===
RCS file: /home/ncvs/src/sys/netinet/igmp.c,v
retrieving revision 1.35
diff -u -p -r1.35 igmp.c
--- netinet/igmp.c 18 Oct 2013 09:04:02 - 1.35
+++ netinet/igmp.c 19 Nov 2013 10:07:24 -
@@ -193,6 +193,7 @@ igmp_input(struct mbuf *m, ...)
struct igmp *igmp;
int igmplen;
int minlen;
+ struct ifmaddr *ifma;
struct in_multi *inm;
struct router_info *rti;
struct in_ifaddr *ia;
@@ -266,7 +267,10 @@ igmp_input(struct mbuf *m, ...)
* except those that are already running and those
* that belong to a local group (224.0.0.X).
*/
- IN_FOREACH_MULTI(ia, ifp, inm) {
+ TAILQ_FOREACH(ifma, ifp-if_maddrlist, ifma_list) {
+ if (ifma-ifma_addr-sa_family != AF_INET)
+ continue;
+ inm = ifmatoinm(ifma);
if (inm-inm_timer == 0
!IN_LOCAL_GROUP(inm-inm_addr.s_addr)) {
inm-inm_state = IGMP_DELAYING_MEMBER;
@@ -294,7 +298,10 @@ igmp_input(struct mbuf *m, ...)
* timers already running, check if they need to be
* reset.
*/
- IN_FOREACH_MULTI(ia, ifp, inm) {
+ TAILQ_FOREACH(ifma, ifp-if_maddrlist, ifma_list) {
+ if (ifma-ifma_addr-sa_family != AF_INET)
+ continue;
+ inm = ifmatoinm(ifma);
if (!IN_LOCAL_GROUP(inm-inm_addr.s_addr)
(ip-ip_dst.s_addr == INADDR_ALLHOSTS_GROUP
||
ip-ip_dst.s_addr ==
inm-inm_addr.s_addr)) {
@@ -479,6 +486,8 @@ void
igmp_leavegroup(struct in_multi *inm)
{
+ int s = splsoftnet();
+
switch (inm-inm_state) {
case IGMP_DELAYING_MEMBER:
case IGMP_IDLE_MEMBER:
@@ -494,6 +503,7 @@ igmp_leavegroup(struct in_multi *inm)
case IGMP_SLEEPING_MEMBER:
break;
}
+ splx(s);
}
void
@@ -521,11 +531,14 @@ void
igmp_checktimer(struct ifnet *ifp)
{
struct in_multi *inm;
- struct in_ifaddr
Re: inteldrm diff
On Sun, Nov 17, 2013 at 10:48:41PM +0100, Mark Kettenis wrote: The diff below is a fairly large diff that moves the gtt management into the inteldrm driver. While this diff might fix some of the issues people have been reporting with inteldrm, I don't expect it to fix most of those issues. This brings our codebase closer to what Linux has though, and this will enable other changes that will address those issues. There is one functional change though. This will take over the gtt entries that are mapping stolen graphics memory. This is what Linux does as well, so it should be safe. And it will give you a bit more space to map graphics objects into the aperture. If you didn't understand all that, don't worry. Just give this diff a try and test for regressions. And that means I just want to know about things that stopped working with this diff applied. Thanks a lot, this seems to improve things in GNOME for me. The large icons in the actitity overview are not corrupt anymore. I am still seeing some icon corruption though. This shows a 'shutdown' icon in the gnome menu which gets corrupted on mouse hover: http://stsp.name/images/broken-menu-icon.png
Re: hiding struct ifnet diff #4v2: _KERNEL
On 19/11/13(Tue) 15:25, Mike Belopuhov wrote: Apparently, this leads to some funny results. There are a bunch of prototypes under ifndef _KERNEL: #ifndef _KERNEL __BEGIN_DECLS unsigned int if_nametoindex(const char *); char*if_indextoname(unsigned int, char *); struct if_nameindex *if_nameindex(void); voidif_freenameindex(struct if_nameindex *); __END_DECLS #endif That, when hidden by the netstat (it does #define _KERNEL) produces undefined symbols at linkage time: % nm ./obj/netstat | grep if_indextoname U if_indextoname Which results in all kinds of crashes :( I can't think of any way to resolve it other than including if.h twice: once with _KERNEL, once without. But that's going to be a huge overkill for ports. Indeed, here's what guenther@ told me some months ago when I tried to do something similar: On 04/08/13(Sun) 00:53, Philip Guenther wrote: Hmm. While I fully agree with hiding declarations for kernel functions and variable behind #ifdef _KERNEL, I'm not completely convinced for types (including structs) and #defines, particularly when they may be useful from programs analyzing crash dumps, or even at runtime using kvm_read(). #defining _KERNEL in userspace programs is a horrible and incredibly fragile workaround, as header dependencies mean these create ordering dependencies. Adding or removing a #include from a kernel header can break userspace programs as the headers seen with or without _KERNEL change. Need the _KERNEL _and_ !_KERNEL parts of a header? Haha, you're screwed! Is there a better way to handle this? What do people think of the apparent convention of having a FOOvar.h header for internal stuff while FOO.h has everything that normal (non-kernel probing) programs need? I.e., instead of having to #define _KERNEL, a program that needs kernel internal structure definitions would pull in the FOOvar.h file. Is that better?
Re: CVS: cvs.openbsd.org: src
I'm inclined to agree with marc here - we bump minors on api additions - and yes, it was stubbed there before so it's not really an addition but it was stubbed to fail and had to be worked around - bump the minor - not like it's a big deal. On Tue, Nov 19, 2013 at 12:02 AM, Marc Espie es...@nerim.net wrote: On Tue, Nov 19, 2013 at 12:11:17AM -0500, Ted Unangst wrote: On Mon, Nov 18, 2013 at 18:49, Philip Guenther wrote: btw, no library version change because the function stubs already existed. Hmm, since this is actually offering new functionality (by sem_open() and friends no longer always failing), I think it a minor bump would be appropriate. Consider that a program with an autoconf test of sem_open() will now return a different answer, just as if sem_open() was completely new. no? I hear you, but disagree. We fix program disabling bugs in libraries frequently without bumping. I have always thought of library versioning being more about program integrity, as in all the pieces you expect to find are all there, but it doesn't say anything about the inner workings of the pieces. As theo says, there are other library bumps later, but you're wrong. Use-case: new packages, slightly older snapshots. New packages actually make use of sem_open, because of said added functionality. Without a bump, pkg_add will allow to add them, and they won't work, because the functionality wasn't there... It is added functionality. It's not a minor bugfix.
Re: CVS: cvs.openbsd.org: src
2013/11/19 Bob Beck b...@obtuse.com: I'm inclined to agree with marc here - we bump minors on api additions - and yes, it was stubbed there before so it's not really an addition but it was stubbed to fail and had to be worked around - bump the minor - not like it's a big deal. On Tue, Nov 19, 2013 at 12:02 AM, Marc Espie es...@nerim.net wrote: On Tue, Nov 19, 2013 at 12:11:17AM -0500, Ted Unangst wrote: On Mon, Nov 18, 2013 at 18:49, Philip Guenther wrote: btw, no library version change because the function stubs already existed. Hmm, since this is actually offering new functionality (by sem_open() and friends no longer always failing), I think it a minor bump would be appropriate. Consider that a program with an autoconf test of sem_open() will now return a different answer, just as if sem_open() was completely new. no? I hear you, but disagree. We fix program disabling bugs in libraries frequently without bumping. I have always thought of library versioning being more about program integrity, as in all the pieces you expect to find are all there, but it doesn't say anything about the inner workings of the pieces. As theo says, there are other library bumps later, but you're wrong. Use-case: new packages, slightly older snapshots. New packages actually make use of sem_open, because of said added functionality. Without a bump, pkg_add will allow to add them, and they won't work, because the functionality wasn't there... It is added functionality. It's not a minor bugfix. I know at least one software piece for which changing the behaviour of sem_open() changes the behaviour of this software itself - KSharedDataCache from kdelibs (the one I've talked on EuroBSDCon, btw). It tries at run-time to call sem_open(foo, 1), and if it fails, goes other way; and particular execution path affects the on-disk structures, too! In case of KSharedDataCache it isn't really an issue (cache could be rebuilt in the worst case), but there could be others in ports with much worse effects. I mean, behavior change in this case should be probably accompanied with major lib version bump, so we could at least differentiate packages. -- WBR, Vadim Zhukov
RTL8111EVL interface on 5.4
I'm looking at a board with the Realtek RTL8111EVL NIC. I believe it's the same as the RTL8111E. Can anyone confirm/deny that this card works with 5.4? I couldn't find it listed in the re or rl manpages. This is the device http://jetwaycomputer.com/JBC373F38.html
Re: RTL8111EVL interface on 5.4
Kenta Suzumoto [ken...@hush.com] wrote: I'm looking at a board with the Realtek RTL8111EVL NIC. I believe it's the same as the RTL8111E. Can anyone confirm/deny that this card works with 5.4? I couldn't find it listed in the re or rl manpages. This is the device http://jetwaycomputer.com/JBC373F38.html It is likely to work fine. All recent Realtek IDs are supported. Some newer Realtek-based systems only work with MSI interrupts, you'll need a -current snapshot to use one of those.
Re: Small patch for fmt(1)
On Mon, 18 Nov 2013 22:16:54 EST Eitan Adler wrote: Hi all, clang gives a warning when building fmt(1): fmt.c:400:35: warning: passing 'char *' to parameter of type 'const unsigned char *' converts between pointers to integer types with different sign might_be_header takes a pointer to unsigned char. However there is no reason for this to be the case. The patch bellow fixes that. In addition it adds 'const' to the type of 'line'. If the only problem is the call to isupper(), then one easy and useful solution is to define a macro called isupperch(), and use that instead. I've come across code in many different projects where a programmer blindly passes a (char *) into the is*() functions, and in some cases that mistake has caused real run-time bugs. It isn't just a dumb warning from an over-zealous compiler. And the real run-time bugs may not show up on a given hardware platform, depending on whether 'plain char' is the same as 'signed char' or 'unsigned char'. So even programmers who have exhaustively tested their code may not see any run-time bugs depending on which platform they are testing on. In any case, here are examples of what I use for macros: /* * All the following take a parameter of 'int', but expect values in the * range of unsigned char. Define wrappers which take values of type 'char', * whether signed or unsigned, and ensure they end up in the right range. */ #define isdigitch(Anychar) isdigit((u_char)(Anychar)) #define islowerch(Anychar) islower((u_char)(Anychar)) #define isupperch(Anychar) isupper((u_char)(Anychar)) #define tolowerch(Anychar) tolower((u_char)(Anychar)) -- Garance Alistair Drosehn= dro...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy NY
linebuffering diff for tr(1)
Hi,
here is a diff that adds optional linebuffering to tr(1) with command
line switch -u like in sed(1). I need this to remove '\r' characters
from a continues input steam which lines have to be there immediately.
Please write me if something is wrong with this diff or the change
itself. I will fix it.
bye,
Jan
Index: tr.1
===
RCS file: /cvs/src/usr.bin/tr/tr.1,v
retrieving revision 1.20
diff -u -p -r1.20 tr.1
--- tr.114 Aug 2013 08:39:27 - 1.20
+++ tr.119 Nov 2013 20:46:33 -
@@ -41,18 +41,18 @@
.Nd translate characters
.Sh SYNOPSIS
.Nm tr
-.Op Fl cs
+.Op Fl csu
.Ar string1 string2
.Nm tr
-.Op Fl c
+.Op Fl cu
.Fl d
.Ar string1
.Nm tr
-.Op Fl c
+.Op Fl cu
.Fl s
.Ar string1
.Nm tr
-.Op Fl c
+.Op Fl cu
.Fl ds
.Ar string1 string2
.Sh DESCRIPTION
@@ -86,6 +86,14 @@ or
.Ar string2 )
in the input into a single instance of the character.
This occurs after all deletion and translation is completed.
+.It Fl u
+Force output to be line buffered,
+printing each line as it becomes available.
+By default, output is line buffered when standard output is a terminal
+and block buffered otherwise.
+See
+.Xr setbuf 3
+for a more detailed explanation.
.El
.Pp
In the first synopsis form, the characters in
@@ -284,6 +292,10 @@ The
utility is compliant with the
.St -p1003.1-2008
specification.
+.Pp
+The flag
+.Op Fl u
+is an extension to that specification.
.Pp
System V has historically implemented character ranges using the syntax
.Dq [c-c]
Index: tr.c
===
RCS file: /cvs/src/usr.bin/tr/tr.c,v
retrieving revision 1.15
diff -u -p -r1.15 tr.c
--- tr.c27 Oct 2009 23:59:46 - 1.15
+++ tr.c19 Nov 2013 20:46:33 -
@@ -88,7 +88,7 @@ main(int argc, char *argv[])
int cflag, dflag, sflag, isstring2;
cflag = dflag = sflag = 0;
- while ((ch = getopt(argc, argv, cds)) != -1)
+ while ((ch = getopt(argc, argv, cdsu)) != -1)
switch((char)ch) {
case 'c':
cflag = 1;
@@ -99,6 +99,9 @@ main(int argc, char *argv[])
case 's':
sflag = 1;
break;
+ case 'u':
+ setlinebuf(stdout);
+ break;
case '?':
default:
usage();
@@ -239,9 +242,9 @@ static void
usage(void)
{
fprintf(stderr,
- usage: tr [-cs] string1 string2\n
- tr [-c] -d string1\n
- tr [-c] -s string1\n
- tr [-c] -ds string1 string2\n);
+ usage: tr [-csu] string1 string2\n
+ tr [-cu] -d string1\n
+ tr [-cu] -s string1\n
+ tr [-cu] -ds string1 string2\n);
exit(1);
}
Re: linebuffering diff for tr(1)
In general, new non-standard options are bad.
Basically, if we add this someone will use it in a script. Then it will
become non-portable. You cannot just invent something on your own like
this, without doing research to find out if someone else added a different
option. I don't see evidence of that, so the gut answer is no.
here is a diff that adds optional linebuffering to tr(1) with command
line switch -u like in sed(1). I need this to remove '\r' characters
from a continues input steam which lines have to be there immediately.
Please write me if something is wrong with this diff or the change
itself. I will fix it.
bye,
Jan
Index: tr.1
===
RCS file: /cvs/src/usr.bin/tr/tr.1,v
retrieving revision 1.20
diff -u -p -r1.20 tr.1
--- tr.1 14 Aug 2013 08:39:27 - 1.20
+++ tr.1 19 Nov 2013 20:46:33 -
@@ -41,18 +41,18 @@
.Nd translate characters
.Sh SYNOPSIS
.Nm tr
-.Op Fl cs
+.Op Fl csu
.Ar string1 string2
.Nm tr
-.Op Fl c
+.Op Fl cu
.Fl d
.Ar string1
.Nm tr
-.Op Fl c
+.Op Fl cu
.Fl s
.Ar string1
.Nm tr
-.Op Fl c
+.Op Fl cu
.Fl ds
.Ar string1 string2
.Sh DESCRIPTION
@@ -86,6 +86,14 @@ or
.Ar string2 )
in the input into a single instance of the character.
This occurs after all deletion and translation is completed.
+.It Fl u
+Force output to be line buffered,
+printing each line as it becomes available.
+By default, output is line buffered when standard output is a terminal
+and block buffered otherwise.
+See
+.Xr setbuf 3
+for a more detailed explanation.
.El
.Pp
In the first synopsis form, the characters in
@@ -284,6 +292,10 @@ The
utility is compliant with the
.St -p1003.1-2008
specification.
+.Pp
+The flag
+.Op Fl u
+is an extension to that specification.
.Pp
System V has historically implemented character ranges using the syntax
.Dq [c-c]
Index: tr.c
===
RCS file: /cvs/src/usr.bin/tr/tr.c,v
retrieving revision 1.15
diff -u -p -r1.15 tr.c
--- tr.c 27 Oct 2009 23:59:46 - 1.15
+++ tr.c 19 Nov 2013 20:46:33 -
@@ -88,7 +88,7 @@ main(int argc, char *argv[])
int cflag, dflag, sflag, isstring2;
cflag = dflag = sflag = 0;
- while ((ch = getopt(argc, argv, cds)) != -1)
+ while ((ch = getopt(argc, argv, cdsu)) != -1)
switch((char)ch) {
case 'c':
cflag = 1;
@@ -99,6 +99,9 @@ main(int argc, char *argv[])
case 's':
sflag = 1;
break;
+ case 'u':
+ setlinebuf(stdout);
+ break;
case '?':
default:
usage();
@@ -239,9 +242,9 @@ static void
usage(void)
{
fprintf(stderr,
- usage: tr [-cs] string1 string2\n
-tr [-c] -d string1\n
-tr [-c] -s string1\n
-tr [-c] -ds string1 string2\n);
+ usage: tr [-csu] string1 string2\n
+tr [-cu] -d string1\n
+tr [-cu] -s string1\n
+tr [-cu] -ds string1 string2\n);
exit(1);
}
Re: linebuffering diff for tr(1)
On 2013/11/19 14:10, Theo de Raadt wrote:
In general, new non-standard options are bad.
Basically, if we add this someone will use it in a script. Then it will
become non-portable. You cannot just invent something on your own like
this, without doing research to find out if someone else added a different
option. I don't see evidence of that, so the gut answer is no.
Only FreeBSD/Dragonfly seem to use -u in tr. How about sed -u instead?
here is a diff that adds optional linebuffering to tr(1) with command
line switch -u like in sed(1). I need this to remove '\r' characters
from a continues input steam which lines have to be there immediately.
Please write me if something is wrong with this diff or the change
itself. I will fix it.
bye,
Jan
Index: tr.1
===
RCS file: /cvs/src/usr.bin/tr/tr.1,v
retrieving revision 1.20
diff -u -p -r1.20 tr.1
--- tr.114 Aug 2013 08:39:27 - 1.20
+++ tr.119 Nov 2013 20:46:33 -
@@ -41,18 +41,18 @@
.Nd translate characters
.Sh SYNOPSIS
.Nm tr
-.Op Fl cs
+.Op Fl csu
.Ar string1 string2
.Nm tr
-.Op Fl c
+.Op Fl cu
.Fl d
.Ar string1
.Nm tr
-.Op Fl c
+.Op Fl cu
.Fl s
.Ar string1
.Nm tr
-.Op Fl c
+.Op Fl cu
.Fl ds
.Ar string1 string2
.Sh DESCRIPTION
@@ -86,6 +86,14 @@ or
.Ar string2 )
in the input into a single instance of the character.
This occurs after all deletion and translation is completed.
+.It Fl u
+Force output to be line buffered,
+printing each line as it becomes available.
+By default, output is line buffered when standard output is a terminal
+and block buffered otherwise.
+See
+.Xr setbuf 3
+for a more detailed explanation.
.El
.Pp
In the first synopsis form, the characters in
@@ -284,6 +292,10 @@ The
utility is compliant with the
.St -p1003.1-2008
specification.
+.Pp
+The flag
+.Op Fl u
+is an extension to that specification.
.Pp
System V has historically implemented character ranges using the syntax
.Dq [c-c]
Index: tr.c
===
RCS file: /cvs/src/usr.bin/tr/tr.c,v
retrieving revision 1.15
diff -u -p -r1.15 tr.c
--- tr.c27 Oct 2009 23:59:46 - 1.15
+++ tr.c19 Nov 2013 20:46:33 -
@@ -88,7 +88,7 @@ main(int argc, char *argv[])
int cflag, dflag, sflag, isstring2;
cflag = dflag = sflag = 0;
- while ((ch = getopt(argc, argv, cds)) != -1)
+ while ((ch = getopt(argc, argv, cdsu)) != -1)
switch((char)ch) {
case 'c':
cflag = 1;
@@ -99,6 +99,9 @@ main(int argc, char *argv[])
case 's':
sflag = 1;
break;
+ case 'u':
+ setlinebuf(stdout);
+ break;
case '?':
default:
usage();
@@ -239,9 +242,9 @@ static void
usage(void)
{
fprintf(stderr,
- usage: tr [-cs] string1 string2\n
- tr [-c] -d string1\n
- tr [-c] -s string1\n
- tr [-c] -ds string1 string2\n);
+ usage: tr [-csu] string1 string2\n
+ tr [-cu] -d string1\n
+ tr [-cu] -s string1\n
+ tr [-cu] -ds string1 string2\n);
exit(1);
}
relayd: crash with two listen on (one is ssl)
Hi,
In relayd, if a relay is configured with two listen on directives, one
with ssl and one without. In the relay_inherit function the ssl pointers
(cert and key) are copied to the latter, and used/freed even if F_SSL is
not set. This causes a double free later in purge_relay.
relay http {
listen on 127.0.0.1 port 4433 ssl
listen on 127.0.0.1 port 8080
forward with ssl to 127.0.0.1 port 443
}
There following patch fixes this.
--- usr.sbin/relayd/parse.y.origTue Nov 19 22:10:48 2013
+++ usr.sbin/relayd/parse.y Tue Nov 19 22:09:41 2013
@@ -2809,6 +2809,12 @@
rb-rl_conf.port = rc.port;
rb-rl_conf.flags =
(ra-rl_conf.flags ~F_SSL) | (rc.flags F_SSL);
+ if (!(rb-rl_conf.flags F_SSL)) {
+ rb-rl_ssl_cert = NULL;
+ rb-rl_conf.ssl_cert_len = 0;
+ rb-rl_ssl_key = NULL;
+ rb-rl_conf.ssl_key_len = 0;
+ }
TAILQ_INIT(rb-rl_tables);
rb-rl_conf.id = ++last_relay_id;
enable relaxed fencing on inteldrm
This may give a speedup in some cases as we will allocate less memory up front. It needs to be tested across a diverse set of hardware for regressions however. Requires the gtt changes kettenis recently committed. Index: i915_dma.c === RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_dma.c,v retrieving revision 1.11 diff -u -p -r1.11 i915_dma.c --- i915_dma.c 19 Nov 2013 19:14:09 - 1.11 +++ i915_dma.c 20 Nov 2013 02:10:31 - @@ -105,11 +105,7 @@ i915_getparam(struct drm_device *dev, vo value = intel_ring_initialized(dev_priv-ring[BCS]); break; case I915_PARAM_HAS_RELAXED_FENCING: -#ifdef notyet value = 1; -#else - return -EINVAL; -#endif break; case I915_PARAM_HAS_COHERENT_RINGS: value = 1;
sem_open goldilocks
We want to be sure the shared semaphore file is sized just right.
If it's not perfect, we'd better be creating it, and if we are
creating it, it'd better be empty.
Index: rthread_sem.c
===
RCS file: /cvs/src/lib/librthread/rthread_sem.c,v
retrieving revision 1.12
diff -u -p -r1.12 rthread_sem.c
--- rthread_sem.c 20 Nov 2013 03:16:39 - 1.12
+++ rthread_sem.c 20 Nov 2013 03:32:36 -
@@ -338,7 +338,17 @@ sem_open(const char *name, int oflag, ..
errno = EPERM;
return (semp);
}
- if (sb.st_size SEM_MMAP_SIZE) {
+ if (sb.st_size != SEM_MMAP_SIZE) {
+ if (!(oflag O_CREAT)) {
+ close(fd);
+ errno = EINVAL;
+ return (semp);
+ }
+ if (sb.st_size != 0) {
+ close(fd);
+ errno = EINVAL;
+ return (semp);
+ }
if (ftruncate(fd, SEM_MMAP_SIZE) == -1) {
oerrno = errno;
close(fd);
Re: initial i217/i218 Haswell Ethernet support for em(4)
On Tue, Nov 19, 2013 at 01:09:32AM +1100, Jonathan Gray wrote:
On Sat, Nov 16, 2013 at 10:42:05AM +0100, Markus Hennecke wrote:
On Sat, 9 Nov 2013, Jonathan Gray wrote:
This adds the initial bits for the i217/i218 PHY and the
Lynx Point PCH found in Haswell systems.
Doesn't include the new workarounds yet and follows
the pch2/82579 paths for now but this seems to be enough
to make a desktop machine with I217-LM work
This fails for the I217-V with an EEPROM invalid checksum error:
Here is a revised diff with different eeprom bank logic
from FreeBSD as suggested by Masanobu SAITOH:
And here is a version that should fix gigabit autoneg:
Index: if_em.c
===
RCS file: /cvs/src/sys/dev/pci/if_em.c,v
retrieving revision 1.271
diff -u -p -r1.271 if_em.c
--- if_em.c 15 Nov 2013 14:53:03 - 1.271
+++ if_em.c 16 Nov 2013 09:35:41 -
@@ -130,6 +130,10 @@ const struct pci_matchid em_devices[] =
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82578DM },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82579LM },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82579V },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I217_LM },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I217_V },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I218_LM },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I218_V },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82580_COPPER },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82580_FIBER },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82580_SERDES },
@@ -788,6 +792,7 @@ em_init(void *arg)
break;
case em_pchlan:
case em_pch2lan:
+ case em_pch_lpt:
pba = E1000_PBA_26K;
break;
default:
@@ -1626,7 +1631,8 @@ em_allocate_pci_resources(struct em_soft
sc-hw.mac_type == em_ich9lan ||
sc-hw.mac_type == em_ich10lan ||
sc-hw.mac_type == em_pchlan ||
- sc-hw.mac_type == em_pch2lan) {
+ sc-hw.mac_type == em_pch2lan ||
+ sc-hw.mac_type == em_pch_lpt) {
val = pci_conf_read(pa-pa_pc, pa-pa_tag, EM_FLASH);
if (PCI_MAPREG_TYPE(val) != PCI_MAPREG_TYPE_MEM) {
printf(: flash is not mem space\n);
Index: if_em_hw.c
===
RCS file: /cvs/src/sys/dev/pci/if_em_hw.c,v
retrieving revision 1.73
diff -u -p -r1.73 if_em_hw.c
--- if_em_hw.c 7 Aug 2013 01:06:34 - 1.73
+++ if_em_hw.c 20 Nov 2013 03:32:03 -
@@ -179,6 +179,7 @@ int32_t em_get_pcs_speed_and_duplex_825
uint16_t *);
int32_tem_set_eee_i350(struct em_hw *);
int32_tem_set_eee_pchlan(struct em_hw *);
+int32_tem_valid_nvm_bank_detect_ich8lan(struct em_hw *,
uint32_t *);
/* IGP cable length table */
@@ -255,6 +256,9 @@ em_set_phy_type(struct em_hw *hw)
case I82579_E_PHY_ID:
hw-phy_type = em_phy_82579;
break;
+ case I217_E_PHY_ID:
+ hw-phy_type = em_phy_i217;
+ break;
case I82580_I_PHY_ID:
case I350_I_PHY_ID:
hw-phy_type = em_phy_82580;
@@ -568,6 +572,12 @@ em_set_mac_type(struct em_hw *hw)
case E1000_DEV_ID_PCH2_LV_V:
hw-mac_type = em_pch2lan;
break;
+ case E1000_DEV_ID_PCH_LPT_I217_LM:
+ case E1000_DEV_ID_PCH_LPT_I217_V:
+ case E1000_DEV_ID_PCH_LPTLP_I218_LM:
+ case E1000_DEV_ID_PCH_LPTLP_I218_V:
+ hw-mac_type = em_pch_lpt;
+ break;
case E1000_DEV_ID_EP80579_LAN_1:
hw-mac_type = em_icp_;
hw-icp__port_num = 0;
@@ -591,6 +601,7 @@ em_set_mac_type(struct em_hw *hw)
case em_ich10lan:
case em_pchlan:
case em_pch2lan:
+ case em_pch_lpt:
hw-swfwhw_semaphore_present = TRUE;
hw-asf_firmware_present = TRUE;
break;
@@ -682,6 +693,7 @@ em_set_media_type(struct em_hw *hw)
case em_ich10lan:
case em_pchlan:
case em_pch2lan:
+ case em_pch_lpt:
case em_82573:
case em_82574:
/*
@@ -838,6 +850,7 @@ em_reset_hw(struct em_hw *hw)
case em_ich10lan:
case em_pchlan:
case em_pch2lan:
+ case em_pch_lpt:
if (!hw-phy_reset_disable
em_check_phy_reset_block(hw) == E1000_SUCCESS) {
/*
@@ -973,7 +986,8 @@ em_reset_hw(struct em_hw *hw)
hw-mac_type == em_ich9lan ||
hw-mac_type == em_ich10lan ||
hw-mac_type == em_pchlan ||
- hw-mac_type == em_pch2lan) {
+ hw-mac_type == em_pch2lan ||
+ hw-mac_type == em_pch_lpt) {
uint32_t kab = E1000_READ_REG(hw,
RTL8723AS-VAU
Hi tech@, Driver/help request: RTL8723AS-VAU either in urtwn or new driver. Found on: Lenovo IdeaPad Yoga 13 port 2 addr 3: high speed, power 500 mA, config 1, GW-USValue-EZ(0x7811), GW-USValue-EZ(0x7392), rev 2.00, iSerialNumber 00e04c01 - note serial number urtwn0 port 3 addr 4: high speed, power 500 mA, config 1, USB2.0-CRW(0x0129), Generic(0x0bda), rev 39.60, iSerialNumber 2010020139600 ugen0 (card in question) port 4 addr 5: high speed, self powered, config 1, 802.11n WLAN Adapter(0x1724), Realtek(0x0bda), rev 2.00, iSerialNumber 00e04c01 ugen1 ^ same serial urtwn1 at uhub2 port 4 Realtek 802.11n WLAN Adapter rev 2.00/2.00 addr 5 urtwn1: MAC/BB RTL8188CUS, RF 6052 1T1R, address fu:nf:un:fu:nf Pretty wild card, seeing as it has a PROPRIETARY USB CONNECTOR on the motherboard itself. It is detachable, but highly unlikely it'll plug into anything; its a weird rectangular connector. Hence, highly likely that only someone with this laptop can help. Also, someone can help by checking out chipset differences from classic urtwn and those used by Larry Finger's beta Linux driver for this card @ http://github.com/lwfinger/rtl8723au (doing this ATM) Yet someone else suggested adding the product ID to dev/usb/usbdevs and if_urtwn.c and changing loadfirmware to the strange and undocumented urtwn-rtl8723fw. Not much luck here, got - urtwn0: timeout waiting for firmware readiness I'm not a driver expert but can anyone tell if this card could be added to urtwn? Or would a whole new driver need to be implemented (due to the chipset)? Thanks! Jean
