Re: if_detach() addresses cleanup
On 22/01/14(Wed) 11:46, Martin Pieuchot wrote:
Network addresses added to the interface local list thought ifa_add()
are the link-local address and the IPv4/6 ones.
Since if_detach() now calls in_ifdetach(), there should be no address
left on the list apart from the link-layer one at this stage. So the
diff below removes it directly, there's no need for a loop anymore.
I left a check for safety afterward...
ok?
Still looking for oks...
Index: net/if.c
===
RCS file: /home/ncvs/src/sys/net/if.c,v
retrieving revision 1.279
diff -u -p -r1.279 if.c
--- net/if.c 28 Nov 2013 10:16:44 - 1.279
+++ net/if.c 7 Jan 2014 11:57:09 -
@@ -359,12 +359,10 @@ if_free_sadl(struct ifnet *ifp)
s = splnet();
rtinit(ifa, RTM_DELETE, 0);
-#if 0
ifa_del(ifp, ifa);
+ ifafree(ifp-if_lladdr);
ifp-if_lladdr = NULL;
-#endif
ifp-if_sadl = NULL;
-
splx(s);
}
@@ -587,27 +585,22 @@ do { \
if (ISSET(ifp-if_xflags, IFXF_TXREADY))
TAILQ_REMOVE(iftxlist, ifp, if_txlist);
- /*
- * Deallocate private resources.
- */
- while ((ifa = TAILQ_FIRST(ifp-if_addrlist)) != NULL) {
- ifa_del(ifp, ifa);
- /* XXX if_free_sadl needs this */
- if (ifa == ifp-if_lladdr)
- continue;
-
- ifa-ifa_ifp = NULL;
- ifafree(ifa);
- }
-
while ((ifg = TAILQ_FIRST(ifp-if_groups)) != NULL)
if_delgroup(ifp, ifg-ifgl_group-ifg_group);
if_free_sadl(ifp);
- ifp-if_lladdr-ifa_ifp = NULL;
- ifafree(ifp-if_lladdr);
- ifp-if_lladdr = NULL;
+ /* We should not have any address left at this point. */
+ if (!TAILQ_EMPTY(ifp-if_addrlist)) {
+#ifdef DIAGNOSTIC
+ printf(%s: address list non empty\n, ifp-if_xname);
+#endif
+ while ((ifa = TAILQ_FIRST(ifp-if_addrlist)) != NULL) {
+ ifa_del(ifp, ifa);
+ ifa-ifa_ifp = NULL;
+ ifafree(ifa);
+ }
+ }
free(ifp-if_addrhooks, M_TEMP);
free(ifp-if_linkstatehooks, M_TEMP);
Sync pthread_set_name_np.3 with pthread_np.h
Index: pthread_set_name_np.3 === RCS file: /cvs/src/lib/libpthread/man/pthread_set_name_np.3,v retrieving revision 1.5 diff -u -p -r1.5 pthread_set_name_np.3 --- pthread_set_name_np.3 5 Jun 2013 03:44:50 - 1.5 +++ pthread_set_name_np.3 6 Mar 2014 07:59:58 - @@ -10,7 +10,7 @@ .In pthread.h .In pthread_np.h .Ft void -.Fn pthread_set_name_np pthread_t thread char *name +.Fn pthread_set_name_np pthread_t thread const char *name .Sh DESCRIPTION The .Fn pthread_set_name_np
Re: carp BACKUP and NA
On 06/03/14(Thu) 09:34, Martin Pieuchot wrote:
On 19/02/14(Wed) 12:53, Martin Pieuchot wrote:
Generally, when a NA is received we check if the receiving interface
has the target address advertised and if it's the case we warn about
duplicate addresses and bail.
But in the case of a carp interface in BACKUP state it's different. In
this case we have a hack that sets the ifa to NULL and continue. This
hack relies on the fact that no cache entry will be found later on
(because it was removed when the state switch to BACKUP) or that there
is no lladdr change in the NA (like it is right now) to work properly.
So instead of expecting such things, simply ignore NAs with matching
address on carp BACKUP nodes since they are more likely to come from
the carp MASTER.
Less is more, ok?
Anybody?
And now a correct version without a typo (|| should be ) spotted by
sthen@. Here's a freshly retested the diff:
Index: netinet6/nd6_nbr.c
===
RCS file: /home/ncvs/src/sys/netinet6/nd6_nbr.c,v
retrieving revision 1.75
diff -u -p -r1.75 nd6_nbr.c
--- netinet6/nd6_nbr.c 24 Jan 2014 12:20:22 - 1.75
+++ netinet6/nd6_nbr.c 6 Mar 2014 10:08:17 -
@@ -570,9 +570,6 @@ nd6_na_input(struct mbuf *m, int off, in
struct rtentry *rt;
struct sockaddr_dl *sdl;
union nd_opts ndopts;
-#if NCARP 0
- struct sockaddr_dl *proxydl = NULL;
-#endif
char addr[INET6_ADDRSTRLEN], addr0[INET6_ADDRSTRLEN];
if (ip6-ip6_hlim != 255) {
@@ -632,11 +629,6 @@ nd6_na_input(struct mbuf *m, int off, in
}
ifa = in6ifa_ifpwithaddr(ifp, taddr6)-ia_ifa;
-#if NCARP 0
- if (ifp-if_type == IFT_CARP ifa
- !carp_iamatch6(ifp, lladdr, proxydl))
- ifa = NULL;
-#endif
/*
* Target address matches one of my interface address.
@@ -652,8 +644,18 @@ nd6_na_input(struct mbuf *m, int off, in
goto freeit;
}
- /* Just for safety, maybe unnecessary. */
if (ifa) {
+#if NCARP 0
+ struct sockaddr_dl *proxydl = NULL;
+
+ /*
+* Ignore NAs silently for carp addresses if we're not
+* the CARP master.
+*/
+ if (ifp-if_type == IFT_CARP
+ !carp_iamatch6(ifp, lladdr, proxydl))
+ goto freeit;
+#endif
log(LOG_ERR,
nd6_na_input: duplicate IP6 address %s\n,
inet_ntop(AF_INET6, taddr6, addr, sizeof(addr)));
missing ports.tar.gz in snapshot
Hi tech, is there a reason, why there is no ports.tar.gz in the latest snapshot folder? fritjof
Re: missing ports.tar.gz in snapshot
is there a reason, why there is no ports.tar.gz in the latest snapshot folder? At present, it is not being built in the ftp area any more. I'd like to ask. Does anyone find it useful? It is not in sync with the packages beside it.
Re: missing ports.tar.gz in snapshot
On Thu, Mar 6, 2014, at 08:56 AM, Theo de Raadt wrote: is there a reason, why there is no ports.tar.gz in the latest snapshot folder? At present, it is not being built in the ftp area any more. I'd like to ask. Does anyone find it useful? It is not in sync with the packages beside it. I don't use the ports tree at all anymore. That said, I would trust the empirical evidence (FTP logs) more than any on-list answers you might get. -- Shawn K. Quinn skqu...@rushpost.com
Re: missing ports.tar.gz in snapshot
Quoting Theo de Raadt dera...@cvs.openbsd.org: is there a reason, why there is no ports.tar.gz in the latest snapshot folder? At present, it is not being built in the ftp area any more. I'd like to ask. Does anyone find it useful? It is not in sync with the packages beside it. Hi Theo, Sometimes, when a dependency package is missing in snapshots or when the package itself does not work; I have used ports.tar.gz to build the package and test it. This has helped me with testing openldap. qemu, and horde. I suppose this could also be done with cvsync etc., so this is not a request to have ports.tar.gz; but it has been useful. Thanks, Vijay Vijay Sankar, M.Eng., P.Eng. ForeTell Technologies Limited vsan...@foretell.ca - This message was sent using ForeTell-POST 4.9
Re: missing ports.tar.gz in snapshot
On Mar 6, 2014, at 3:13 PM, Vijay Sankar vsan...@foretell.ca wrote: Quoting Theo de Raadt dera...@cvs.openbsd.org: is there a reason, why there is no ports.tar.gz in the latest snapshot folder? At present, it is not being built in the ftp area any more. I'd like to ask. Does anyone find it useful? It is not in sync with the packages beside it. Are all the ports in the packages in snapshots? I seem to remember needing to build some of the things I use to test, but maybe that has changed. I use snapshots when I have time to test, so whatever direction you want to give as far as testing goes, just let us know. devin
Re: missing ports.tar.gz in snapshot
Quoting Theo de Raadt dera...@cvs.openbsd.org: is there a reason, why there is no ports.tar.gz in the latest snapshot folder? At present, it is not being built in the ftp area any more. I'd like to ask. Does anyone find it useful? It is not in sync with the packages beside it. I thought the packages are being build from the ports tree or am I wrong? Hi Theo, Sometimes, when a dependency package is missing in snapshots or when the package itself does not work; I have used ports.tar.gz to build the package and test it. This has helped me with testing openldap. qemu, and horde. I suppose this could also be done with cvsync etc., so this is not a request to have ports.tar.gz; but it has been useful. Thanks, Vijay Vijay Sankar, M.Eng., P.Eng. ForeTell Technologies Limited vsan...@foretell.ca - This message was sent using ForeTell-POST 4.9
Re: missing ports.tar.gz in snapshot
On Thu, Mar 06, 2014 at 03:18:38PM +, Devin Ceartas wrote: On Mar 6, 2014, at 3:13 PM, Vijay Sankar vsan...@foretell.ca wrote: Quoting Theo de Raadt dera...@cvs.openbsd.org: is there a reason, why there is no ports.tar.gz in the latest snapshot folder? At present, it is not being built in the ftp area any more. I'd like to ask. Does anyone find it useful? It is not in sync with the packages beside it. Are all the ports in the packages in snapshots? I seem to remember needing to build some of the things I use to test, but maybe that has changed. I use snapshots when I have time to test, so whatever direction you want to give as far as testing goes, just let us know. devin No, not all ports can be distributed as packages due to license restrictions. -- James Turner
Re: missing ports.tar.gz in snapshot
I'd like to ask. Does anyone find it useful? It is not in sync with the packages beside it. I thought the packages are being build from the ports tree or am I wrong? Sigh. So I can make a tar file available. At a particular moment in time. But the package builts are not done in an instant; far from that, especially on slower machines. So read what I said again. They're not in sync.
Re: missing ports.tar.gz in snapshot
Are all the ports in the packages in snapshots? The best way to get source code from our project is not in tar files, but using the repository-access methods described on the web site and in the FAQ. Then it is easier to move your tree forward in time, rather than downloading files this big, every time. -rw-r--r-- 1 deraadt wheel 21.8M Mar 5 13:14 ports.tar.gz -rw-r--r-- 1 deraadt wheel 160M Mar 5 09:46 src.tar.gz -rw-r--r-- 1 deraadt wheel 110M Mar 5 09:46 xenocara.tar.gz
Re: missing ports.tar.gz in snapshot
On Mar 6, 2014, at 3:34 PM, Theo de Raadt dera...@cvs.openbsd.org wrote: Are all the ports in the packages in snapshots? The best way to get source code from our project is not in tar files, but using the repository-access methods described on the web site and in the FAQ. Then it is easier to move your tree forward in time, rather than downloading files this big, every time. -rw-r--r-- 1 deraadt wheel 21.8M Mar 5 13:14 ports.tar.gz -rw-r--r-- 1 deraadt wheel 160M Mar 5 09:46 src.tar.gz -rw-r--r-- 1 deraadt wheel 110M Mar 5 09:46 xenocara.tar.gz OK, sure, cvs update the ports tree. That works for me. Now that I think about it, I'm sure that's what I've done at least some of the time. No problem.
Re: missing ports.tar.gz in snapshot
I'd like to ask. Does anyone find it useful? It is not in sync with the packages beside it. I thought the packages are being build from the ports tree or am I wrong? Sigh. So I can make a tar file available. At a particular moment in time. But the package builts are not done in an instant; far from that, especially on slower machines. So read what I said again. They're not in sync. Ahh, I see. Thank you for the explanation.
Re: missing ports.tar.gz in snapshot
On 2014/03/06 08:32, Theo de Raadt wrote: I'd like to ask. Does anyone find it useful? It is not in sync with the packages beside it. I thought the packages are being build from the ports tree or am I wrong? Sigh. So I can make a tar file available. At a particular moment in time. But the package builts are not done in an instant; far from that, especially on slower machines. So read what I said again. They're not in sync. I think the main use for the tar files is for people who are behind a restrictive firewall that they can't ssh through to use anoncvs (though there are anoncvs servers which run on alternative ports which is often good enough to get around this). They might also be a bit quicker to fetch in bulk than a cvs checkout, which doesn't stream particularly well over slow net for lots of small files. Personally I'd keep them for releases (which also gives people a base to speed up updates to -current) but probably drop them for snapshots..
Re: missing ports.tar.gz in snapshot
Personally I'd keep them for releases (which also gives people a base to speed up updates to -current) but probably drop them for snapshots.. In the next few hours, the file will be there. (Can one of you select yourself to help care watch this file, and talk just to me about it? I'm changing some stuff as to how it gets updated)
Re: missing ports.tar.gz in snapshot
On Thu, Mar 06, 2014 at 03:18:38PM +, Devin Ceartas wrote: Are all the ports in the packages in snapshots? I seem to remember needing to build some of the things I use to test, but maybe that has changed. There are a few ports not in snapshots, stuff that is not authorized for ftp redistribution. Accidents happen. Sometimes, stuff does not build. That's more frequent on less used architectures. Most builds on amd64 give 100%. All packages referenced in the ports tree that should be on amd64 do build.
Re: missing ports.tar.gz in snapshot
On Thu, 6 Mar 2014, Theo de Raadt wrote: I'd like to ask. Does anyone find it useful? It is not in sync with the packages beside it. I thought the packages are being build from the ports tree or am I wrong? Sigh. So I can make a tar file available. At a particular moment in time. But the package builts are not done in an instant; far from that, especially on slower machines. So read what I said again. They're not in sync. But they are in sync for a release. Or the ports.tar.gz file won't be a part of a release anymore? Regards, David
Re: missing ports.tar.gz in snapshot
So read what I said again. They're not in sync. But they are in sync for a release. Or the ports.tar.gz file won't be a part of a release anymore? Yes, they are in sync for a release. But the Subject says snapshot.
Re: missing ports.tar.gz in snapshot
previously on this list Shawn K. Quinn contributed: Makes very little difference to me. I don't use the ports tree at all anymore. That said, I would trust the empirical evidence (FTP logs) more than any on-list answers you might get. Is there a pkg* tools equivalent to print-run-depends? -- ___ '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) In Other Words - Don't design like polkit or systemd ___
Re: [diff] calendar.birthday
On Wed, Mar 05, 2014 at 08:38:43PM -0800, patrick keshishian wrote: Index: calendar.birthday === RCS file: /cvs/obsd/src/usr.bin/calendar/calendars/calendar.birthday,v retrieving revision 1.57 diff -u -p -u -p -r1.57 calendar.birthday --- calendar.birthday 11 Feb 2014 12:20:34 - 1.57 +++ calendar.birthday 6 Mar 2014 04:37:08 - @@ -77,6 +77,7 @@ 02/17T. J. Watson, Sr. born, 1874 02/17Marion Anderson born, 1902 02/18Ernst Mach born, 1838, philosopher optics pioneer +02/18Michelangelo Buonarroti dies in Rome, Italy, 1564 02/19Nicolas Copernicus born in Thorn, Poland, 1473 02/20Ludwig Boltzmann born, 1844, atomic physics pioneer 02/21Alexis De Rochon born, 1838, developed the spyglass added, thanks! jmc
Re: Sync pthread_set_name_np.3 with pthread_np.h
On Thu, Mar 06, 2014 at 09:02:22AM +0100, Gabriel Linder wrote: Index: pthread_set_name_np.3 === RCS file: /cvs/src/lib/libpthread/man/pthread_set_name_np.3,v retrieving revision 1.5 diff -u -p -r1.5 pthread_set_name_np.3 --- pthread_set_name_np.3 5 Jun 2013 03:44:50 - 1.5 +++ pthread_set_name_np.3 6 Mar 2014 07:59:58 - @@ -10,7 +10,7 @@ .In pthread.h .In pthread_np.h .Ft void -.Fn pthread_set_name_np pthread_t thread char *name +.Fn pthread_set_name_np pthread_t thread const char *name .Sh DESCRIPTION The .Fn pthread_set_name_np fixed, thanks! jmc
Re: fix seekdir(3)
Hi,
back in November 2013, following an idea by guenther@,
i cooked up another optimization for seekdir(3),
then failed to send out the patch. So here it is.
Philip Guenther wrote on Tue, Nov 05, 2013 at 07:57:43PM -0800:
On Wed, 6 Nov 2013, Ingo Schwarze wrote:
* Worst case:
opendir; telldir
then 100.000 times (seekdir; readdir) at that position
= The entry asked for is the very first entry in the buffer,
which cannot be found, because each dirent only contains
the address of the *following* dirent, so each readdir
triggers getdents anyway, but we still search the whole
buffer each time.
While caching the offset of the start of the buffer is possible, it's
not obvious that that case will happen often enough to be worth it.
Hmm, rewinddir() will _always_ be this worst case. Perhaps rewinddir()
should not call seekdir() and just be the two assignments with lseek(),
skipping the scan of the current buffer.
That wouldn't be very useful because after lseek(2), getdents(2) is
required, which is *much* more expensive than searching the buffer.
It would be assisted by the start-o-buffer cache though.
Exactly. Right now, each rewinddir(3) seeks the whole buffer in vain,
wasting 5 microseconds on that, then proceeds to the extremely expensive
getdents(2) anyway, wasting another 100 microseconds.
The patch to cache the cookie of the first directory entry
in addition to all the other entries that we already cache
is relatively simple, see below.
With this patch, rewinddir(3) changes from always being the worst
case to often being the best case (now always the best case for
directories with less than about 500 entries, or for rewinding
before reading less than about 500 entries), no other case becomes
any worse, and some other, less important edge cases improve, too.
What the patch does is:
* Let opendir(3) save the cookie of the first entry of the directory.
* Let seekdir(3) use that saved cookie to move the internal pointers
to that entry when asked to do so, for example on rewinddir(3).
* Let seekdir(3) update that saved cookie when the buffer is exhausted
and when consequently, an lseek(2) had to be done.
* Let seekdir(3) invalidate the buffer by setting the pointer after
its end, instead of to its beginning.
* Have readdir(3) refrain from invalidating the buffer
when asked to return the first element from it.
This comes with only one price: Adding another off_t to the
opaque struct _dirdesc (= DIR), which already contains another
off_t, two long, two int, and two pointers. That's not much
growth, especially since no sane code will allocate large
numbers of DIRs.
As explained last year, this patch reduced typical execution
times of rewinddir(3) on my notebook for about 100 microseconds
to about 0.05 microseconds.
The /usr/src/regress/lib/libc/telldir/ test suite is still happy,
and so are some other, manual tests i have done.
Am i right that, the type DIR being opaque, this patch doesn't
require any libc bump?
Comments, OKs?
Ingo
Index: opendir.c
===
RCS file: /cvs/src/lib/libc/gen/opendir.c,v
retrieving revision 1.26
diff -u -p -r1.26 opendir.c
--- opendir.c 6 Nov 2013 20:35:25 - 1.26
+++ opendir.c 6 Mar 2014 17:14:16 -
@@ -76,7 +76,7 @@ fdopendir(int fd)
dirp = __fdopendir(fd);
if (dirp != NULL) {
/* Record current offset for immediate telldir() */
- dirp-dd_curpos = lseek(fd, 0, SEEK_CUR);
+ dirp-dd_bufpos = dirp-dd_curpos = lseek(fd, 0, SEEK_CUR);
/*
* POSIX doesn't require fdopendir() to set
@@ -116,6 +116,7 @@ __fdopendir(int fd)
dirp-dd_fd = fd;
dirp-dd_lock = NULL;
dirp-dd_curpos = 0;
+ dirp-dd_bufpos = 0;
return (dirp);
}
Index: readdir.c
===
RCS file: /cvs/src/lib/libc/gen/readdir.c,v
retrieving revision 1.20
diff -u -p -r1.20 readdir.c
--- readdir.c 6 Nov 2013 22:26:14 - 1.20
+++ readdir.c 6 Mar 2014 17:14:16 -
@@ -43,9 +43,8 @@ _readdir_unlocked(DIR *dirp, struct dire
*result = NULL;
for (;;) {
- if (dirp-dd_loc = dirp-dd_size)
+ if (dirp-dd_loc = dirp-dd_size) {
dirp-dd_loc = 0;
- if (dirp-dd_loc == 0) {
dirp-dd_size = getdents(dirp-dd_fd, dirp-dd_buf,
dirp-dd_len);
if (dirp-dd_size == 0)
Index: seekdir.c
===
RCS file: /cvs/src/lib/libc/gen/seekdir.c,v
retrieving revision 1.11
diff -u -p -r1.11 seekdir.c
--- seekdir.c 6 Nov 2013 20:35:25 - 1.11
+++ seekdir.c 6 Mar 2014 17:14:16 -
@@ -36,6 +36,13 @@ seekdir(DIR *dirp, long loc)
*/
_MUTEX_LOCK(dirp-dd_lock);
make mandoc -Tlocale the default
Hi,
having fixed the accent issues with mandoc -Tutf8, i have checked
the base system for build system issues with switching the default,
the resulting fixes are included in the following patch.
Anybody wants to check with ports before commit, such that we can do
any necessary cleanup beforehands, as opposed to mopping up
possible fallout afterwards?
Any other feedback is welcome as well, of course.
Note that unless you have set LC_CTYPE in your shell, this will
not change the game for you, or it would be a bug.
Yours,
Ingo
Index: usr.bin/mandoc/main.c
===
RCS file: /cvs/src/usr.bin/mandoc/main.c,v
retrieving revision 1.86
diff -u -p -r1.86 main.c
--- usr.bin/mandoc/main.c 6 Jan 2014 00:53:14 - 1.86
+++ usr.bin/mandoc/main.c 6 Mar 2014 20:28:01 -
@@ -98,7 +98,7 @@ main(int argc, char *argv[])
memset(curp, 0, sizeof(struct curparse));
type = MPARSE_AUTO;
- curp.outtype = OUTT_ASCII;
+ curp.outtype = OUTT_LOCALE;
curp.wlevel = MANDOCLEVEL_FATAL;
defos = NULL;
Index: usr.bin/mandoc/mandoc.1
===
RCS file: /cvs/src/usr.bin/mandoc/mandoc.1,v
retrieving revision 1.56
diff -u -p -r1.56 mandoc.1
--- usr.bin/mandoc/mandoc.1 13 Jul 2013 19:27:46 - 1.56
+++ usr.bin/mandoc/mandoc.1 6 Mar 2014 20:28:07 -
@@ -47,7 +47,7 @@ or
text from stdin, implying
.Fl m Ns Cm andoc ,
and produces
-.Fl T Ns Cm ascii
+.Fl T Ns Cm locale
output.
.Pp
The arguments are as follows:
@@ -76,7 +76,7 @@ See
.Sx Output Formats
for available formats.
Defaults to
-.Fl T Ns Cm ascii .
+.Fl T Ns Cm locale .
.It Fl V
Print version and exit.
.It Fl W Ns Ar level
@@ -173,7 +173,6 @@ arguments, which correspond to output mo
.Bl -tag -width -Tlocale
.It Fl T Ns Cm ascii
Produce 7-bit ASCII output.
-This is the default.
See
.Sx ASCII Output .
.It Fl T Ns Cm html
@@ -186,6 +185,7 @@ Implies
.Fl W Ns Cm warning .
.It Fl T Ns Cm locale
Encode output using the current locale.
+This is the default.
See
.Sx Locale Output .
.It Fl T Ns Cm man
@@ -218,8 +218,8 @@ If multiple input files are specified, t
corresponding filter in-order.
.Ss ASCII Output
Output produced by
-.Fl T Ns Cm ascii ,
-which is the default, is rendered in standard 7-bit ASCII documented in
+.Fl T Ns Cm ascii
+is rendered in standard 7-bit ASCII documented in
.Xr ascii 7 .
.Pp
Font styles are applied by using back-spaced encoding such that an
@@ -335,6 +335,8 @@ relative URI.
.Ss Locale Output
Locale-depending output encoding is triggered with
.Fl T Ns Cm locale .
+This is the default.
+.Pp
This option is not available on all systems: systems without locale
support, or those whose internal representation is not natively UCS-4,
will fall back to
Index: sbin/disklabel/Makefile
===
RCS file: /cvs/src/sbin/disklabel/Makefile,v
retrieving revision 1.54
diff -u -p -r1.54 Makefile
--- sbin/disklabel/Makefile 31 Oct 2013 22:37:17 - 1.54
+++ sbin/disklabel/Makefile 6 Mar 2014 20:28:07 -
@@ -17,7 +17,7 @@ manual.c:
echo '};'; echo 'const int manpage_sz = sizeof(manpage);') manual.c
.else
disklabel.cat8:disklabel.8
- mandoc ${.ALLSRC} ${.TARGET}
+ mandoc -Tascii ${.ALLSRC} ${.TARGET}
manual.c: disklabel.cat8
(echo 'const unsigned char manpage[] = {'; \
Index: sbin/fdisk/Makefile
===
RCS file: /cvs/src/sbin/fdisk/Makefile,v
retrieving revision 1.39
diff -u -p -r1.39 Makefile
--- sbin/fdisk/Makefile 31 Oct 2013 22:37:17 - 1.39
+++ sbin/fdisk/Makefile 6 Mar 2014 20:28:07 -
@@ -40,7 +40,7 @@ manual.c:
echo '};'; echo 'const int manpage_sz = sizeof(manpage);') manual.c
.else
fdisk.cat8:fdisk.8
- mandoc ${.ALLSRC} ${.TARGET}
+ mandoc -Tascii ${.ALLSRC} ${.TARGET}
manual.c: fdisk.cat8
(echo 'const unsigned char manpage[] = {'; \
Index: regress/usr.bin/mandoc/roff/de/Makefile
===
RCS file: /cvs/src/regress/usr.bin/mandoc/roff/de/Makefile,v
retrieving revision 1.1
diff -u -p -r1.1 Makefile
--- regress/usr.bin/mandoc/roff/de/Makefile 2 Jun 2012 23:18:31 -
1.1
+++ regress/usr.bin/mandoc/roff/de/Makefile 6 Mar 2014 20:28:07 -
@@ -23,10 +23,10 @@ ascii-diff-opt: TH.mandoc_ascii_opt Dd.m
${DIFF} ${.CURDIR}/Dd.out_ascii_opt Dd.mandoc_ascii_opt
TH.mandoc_ascii_opt: TH.in
- ${MANDOC} -man ${.ALLSRC} ${.TARGET}
+ ${MANDOC} -Tascii -man ${.ALLSRC} ${.TARGET}
Dd.mandoc_ascii_opt: Dd.in
- ${MANDOC} -mdoc ${.ALLSRC} ${.TARGET}
+ ${MANDOC} -Tascii -mdoc ${.ALLSRC} ${.TARGET}
ascii-clean-opt:
rm -f TH.mandoc_ascii_opt Dd.mandoc_ascii_opt
Re: make mandoc -Tlocale the default
On Thu, Mar 06, 2014 at 21:36, Ingo Schwarze wrote: Hi, having fixed the accent issues with mandoc -Tutf8, i have checked the base system for build system issues with switching the default, the resulting fixes are included in the following patch. Anybody wants to check with ports before commit, such that we can do any necessary cleanup beforehands, as opposed to mopping up possible fallout afterwards? Seems reasonable to me. I went the man.conf route because it's easier for users to revert, but I think there's enough time to shake out the fixes if needed.
Re: make mandoc -Tlocale the default
Hi Ted, Ted Unangst wrote on Thu, Mar 06, 2014 at 04:46:50PM -0500: Seems reasonable to me. I went the man.conf route because it's easier for users to revert, Oh, if somebody really insists in setting LC_CTYPE but wants to see manuals in US-ASCII anyway (huh?), adding -Tascii to mandoc in man.conf(5) will work just fine and isn't hard to do. but I think there's enough time to shake out the fixes if needed. That's what i think as well. Ingo
remove pf_check_congestion()
pf_check_congestion() simply checks if ifq-ifq_congestion is non-zero,
and returns 1 or 0 accordingly. It is only called by pf_test_rule().
Since what pf_check_congestion() does is very trivial and pf_test_rule()
is its only user, would it make sense to remove it and let
pf_test_rule() check ifq-ifq_congestion directly to save a function
call?
Index: pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.868
diff -u -p -r1.868 pf.c
--- pf.c25 Jan 2014 03:39:00 - 1.868
+++ pf.c18 Feb 2014 17:57:42 -
@@ -230,7 +230,6 @@ int pf_compare_state_keys(struct pf_s
struct pf_state*pf_find_state(struct pfi_kif *,
struct pf_state_key_cmp *, u_int, struct mbuf *);
int pf_src_connlimit(struct pf_state **);
-int pf_check_congestion(struct ifqueue *);
int pf_match_rcvif(struct mbuf *, struct pf_rule *);
voidpf_step_into_anchor(int *, struct pf_ruleset **,
struct pf_rule **, struct pf_rule **);
@@ -3159,7 +3158,7 @@ pf_test_rule(struct pf_pdesc *pd, struct
ifq = ip6intrq;
#endif
- if (pd-dir == PF_IN pf_check_congestion(ifq)) {
+ if (pd-dir == PF_IN ifq-ifq_congestion) {
REASON_SET(reason, PFRES_CONGEST);
return (PF_DROP);
}
@@ -6745,15 +6744,6 @@ done:
}
return (action);
-}
-
-int
-pf_check_congestion(struct ifqueue *ifq)
-{
- if (ifq-ifq_congestion)
- return (1);
- else
- return (0);
}
void
