Re: [Patch] Support F13-F24 on PC-122 terminal keyboard
Well, it conflicts with the codes listed in the `USB HID to PS/2 Scan Code Translation Table' Yes, but that document just lists the codes that Windows translates to internally when a USB keyboard is in use. I have no reason to believe that any PS/2 device actually uses them in hardware, and good reason to believe that they don't, (and wouldn't). Hmm. You're right. According to http://www.win.tue.nl/~aeb/linux/kbd/scancodes-5.html the IBM 122 key keyboard, which seems to be the most common 122-key keyboard around, matches the scan codes from your diff. If your IBM keyboard uses different scancodes for the extra function keys, then it would be better to handle them with a specific submap, as already done in the declk or iopener submaps. I'm happy to use a submap for 122 key terminal keyboards, anyway. I think this would be easier. But on the other hand this would restrict the use of the extra keys to the us layout. So for the sake of hypothetical localized 122 key keyboards, I think your diff is the way to go, with a range test added to the PS/2-to-USB map converter to skip those keys. Since most of these functions do not relate to OpenBSD, I set mine to switch between virtual consoles. However, this required a hack to the kernel to disable the need to hold down control and alt to select VC, because that is hard-coded in wskbd.c. That's a different story. We probably need a way to know that a given key has been assigned only one function, and remove the need for the two main command modifiers to be down in that case. Miod
Re: Weird wscons bug (was Re: [Patch] Add repeat key functionality)
Excellent. Try setting the default, though: # wsconsctl keyboard.repeat.deln.default=350 keyboard.repeat.deln.default - 200 In fact, if you check, whenever a user changes the normal value, the default value changes too. So a normal, non-root user can change the values for all of the VCs. Great. No, that was a bug in wsconsctl where it would report the current repeat rate as the default. Thanks for noticing it! Miod
kern malloc simpleq
kern malloc rolls its own linked list code. for the sake of clarity
and to make future changes easier, i'd like to make it a simpleq.
it would be very nice if this could be tested on a few different kinds
of machines. it's not supposed to actually change anything, but that's
what testing is to verify.
Index: sys/malloc.h
===
RCS file: /cvs/src/sys/sys/malloc.h,v
retrieving revision 1.101
diff -u -p -r1.101 malloc.h
--- sys/malloc.h7 Feb 2013 11:06:42 - 1.101
+++ sys/malloc.h21 Mar 2013 06:42:10 -
@@ -35,6 +35,8 @@
#ifndef _SYS_MALLOC_H_
#define_SYS_MALLOC_H_
+#include sys/queue.h
+
#define KERN_MALLOC_BUCKETS1
#define KERN_MALLOC_BUCKET 2
#define KERN_MALLOC_KMEMNAMES 3
@@ -340,11 +342,25 @@ struct kmemusage {
#defineku_pagecnt ku_un.pagecnt
/*
+ * Normally the freelist structure is used only to hold the list pointer
+ * for free objects. However, when running with diagnostics, the first
+ * 8 bytes of the structure is unused except for diagnostic information,
+ * and the free list pointer is at offset 8 in the structure. Since the
+ * first 8 bytes is the portion of the structure most often modified, this
+ * helps to detect memory reuse problems and avoid free list corruption.
+ */
+struct kmem_freelist {
+ int32_t kf_spare0;
+ int16_t kf_type;
+ int16_t kf_spare1;
+ SIMPLEQ_ENTRY(kmem_freelist) kf_flist;
+};
+
+/*
* Set of buckets for each size of memory block that is retained
*/
struct kmembuckets {
- caddr_t kb_next; /* list of free blocks */
- caddr_t kb_last; /* last free block */
+ SIMPLEQ_HEAD(, kmem_freelist) kb_freelist; /* list of free blocks */
u_int64_t kb_calls; /* total calls to allocate this size */
u_int64_t kb_total; /* total number of blocks allocated */
u_int64_t kb_totalfree; /* # of free elements in this bucket */
Index: kern/kern_malloc.c
===
RCS file: /cvs/src/sys/kern/kern_malloc.c,v
retrieving revision 1.95
diff -u -p -r1.95 kern_malloc.c
--- kern/kern_malloc.c 15 Mar 2013 19:10:43 - 1.95
+++ kern/kern_malloc.c 21 Mar 2013 07:43:07 -
@@ -175,25 +175,6 @@ poison_check(void *v, size_t len)
}
-
-/*
- * Normally the freelist structure is used only to hold the list pointer
- * for free objects. However, when running with diagnostics, the first
- * 8 bytes of the structure is unused except for diagnostic information,
- * and the free list pointer is at offset 8 in the structure. Since the
- * first 8 bytes is the portion of the structure most often modified, this
- * helps to detect memory reuse problems and avoid free list corruption.
- */
-struct freelist {
- int32_t spare0;
- int16_t type;
- int16_t spare1;
- caddr_t next;
-};
-#else /* !DIAGNOSTIC */
-struct freelist {
- caddr_t next;
-};
#endif /* DIAGNOSTIC */
#ifndef SMALL_KERNEL
@@ -209,10 +190,10 @@ malloc(unsigned long size, int type, int
{
struct kmembuckets *kbp;
struct kmemusage *kup;
- struct freelist *freep;
+ struct kmem_freelist *freep;
long indx, npg, allocsize;
int s;
- caddr_t va, cp, savedlist;
+ caddr_t va, cp;
#ifdef DIAGNOSTIC
size_t pidx;
int freshalloc;
@@ -270,7 +251,7 @@ malloc(unsigned long size, int type, int
allocsize = round_page(size);
else
allocsize = 1 indx;
- if (kbp-kb_next == NULL) {
+ if (SIMPLEQ_FIRST(kbp-kb_freelist) == NULL) {
npg = atop(round_page(allocsize));
va = (caddr_t)uvm_km_kmemalloc_pla(kmem_map, NULL,
(vsize_t)ptoa(npg), 0,
@@ -311,58 +292,48 @@ malloc(unsigned long size, int type, int
kup-ku_freecnt = kbp-kb_elmpercl;
kbp-kb_totalfree += kbp-kb_elmpercl;
#endif
- /*
-* Just in case we blocked while allocating memory,
-* and someone else also allocated memory for this
-* bucket, don't assume the list is still empty.
-*/
- savedlist = kbp-kb_next;
- kbp-kb_next = cp = va + (npg * PAGE_SIZE) - allocsize;
+ cp = va + (npg * PAGE_SIZE) - allocsize;
for (;;) {
- freep = (struct freelist *)cp;
+ freep = (struct kmem_freelist *)cp;
#ifdef DIAGNOSTIC
/*
* Copy in known text to detect modification
* after freeing.
*/
poison(cp, allocsize);
- freep-type = M_FREE;
+ freep-kf_type = M_FREE;
#endif /* DIAGNOSTIC */
+ SIMPLEQ_INSERT_HEAD(kbp-kb_freelist, freep, kf_flist);
rthread suspension
I'm a GNU Guile 2.0 user, whose latest versions require latest versions of the Boehm garbage collector. This uses the functions pthread_suspend_np and pthread_resume_np, when built on OpenBSD, which don't exist in rthreads. I've read that rthreads are just processes, albeit with a special flag set and sharing certain resources. It seems they can be sent usual signals with pthread_kill. Should sending SIGSTOP and SIGCONT to an rthread have the same behavior of using pthread_suspend_np and pthread_resume_np in the old API? Any information on how I could answer this question myself would be much appreciated, I'm yet quite ignorant on the topic. Any general tips on how an application using the old API should be ported to the new one are also welcome. One question would be, should OpenBSD try to support functions from the old API on top of the new one (would patches in this nature be desirable), or should applications check for OpenBSD versions? Regards, Taylan
Re: rthread suspension
On 2013/03/21 11:03, Taylan Ulrich B. wrote: I'm a GNU Guile 2.0 user, whose latest versions require latest versions of the Boehm garbage collector. This uses the functions pthread_suspend_np and pthread_resume_np, when built on OpenBSD, which don't exist in rthreads. the current boehm-gc port works with rthreads, best way forward is probably to update that to a newer version, maintaining the patches that we have. perhaps the uthread workarounds that we used to have in the port got committed upstream and now need to be reverted?
Re: rthread suspension
Stuart Henderson s...@spacehopper.org writes: the current boehm-gc port works with rthreads, best way forward is probably to update that to a newer version, maintaining the patches that we have. perhaps the uthread workarounds that we used to have in the port got committed upstream and now need to be reverted? I can't be sure but it looks to me like there are some big changes from version 7.0 (OpenBSD 5.2 ports) to 7.2d (latest release) of Boehm GC, which render the patches for the old one useless. What I can be sure about is that 7.2d and the master branch on GitHub don't use the patches from OpenBSD ports, but something that uses pthread_suspend_np. (That way it builds fine without any patching on recent OpenBSD versions up to 5.1, before rthreads became default.) I don't know why they would do that if the 7.0 patches kept working.
i386 ports failures / new binutils
i386 package build is still running, but there are a few common failure modes I've picked up (and at least ffmpeg and gstreamer will have knocked out big chunks of the tree) so I think I'll send this out now. Mostly binutils-related but there may be other failures mixed in (this is the first full i386 build in about a month). - local symbol `environ' in /usr/lib/crt0.o is referenced by DSO multimedia/gstreamer*/plugins-base devel/jdk/1.7 - these look like problems with -Wl,--as-needed and inter library dependencies graphics/ffmpeg - ERROR: libvorbis not found sysutils/coreutils - /usr/local/lib/libintl.so.6.0: undefined reference to `libiconv_open' sysutils/upower - /usr/local/lib/libintl.so.6.0: undefined reference to `libiconv_open' - NLS disabled - no .mo files, pkg fails editors/vim (python flavours) - libpython2.7.so.0.0: undefined reference to `openpty' - Error: suffix or operands invalid for `mov' these are all movl with %eax and two-character registers, e.g. movl%fs, 8(%eax) movl8(%eax), %fs plan9/plan9port lang/io - www/chromium - OSError: [Errno 8] Exec format error - print/texlive/base - configure: error: cannot compute sizeof (wchar_t) (in configure tests of the bundled icu4c; the separate textproc/icu4c did build ok) - www/seamonkey - xpidl.IDLError: error: name 'nsIMsgIdentity' specified twice. - sysutils/gsmartcontrol - `.gnu.linkonce.t._Z11app_pcre_reRKSs' referenced in section `.gnu.linkonce.r._Z11app_pcre_reRKSs' of gsc_main_window.o: defined in discarded section `.gnu.linkonce.t._Z11app_pcre_reRKSs' of gsc_main_window.o
Re: rthread suspension
Stuart Henderson s...@spacehopper.org writes: As I said, perhaps the uthread workarounds that we used to have in the port got committed upstream and now need to be reverted? i.e. _used_ to have, before the change to rthreads. Oh sorry, I understand now. Indeed, the patches in e.g. 5.0 ports seem equivalent to what is now upstream (although not exactly identical). In your opinion, should upstream Boehm GC try to support pre-rthreads OpenBSD versions as well, or drop that and only support rthreads? (Or do the new patches work for both?) Any way, the new patches will have to be integrated to master. Would anyone like to take that job? If not, I'd like to try, although I don't know how long it would take for me.
Re: rthread suspension
On 2013/03/21 12:32, Taylan Ulrich B. wrote: Stuart Henderson s...@spacehopper.org writes: As I said, perhaps the uthread workarounds that we used to have in the port got committed upstream and now need to be reverted? i.e. _used_ to have, before the change to rthreads. Oh sorry, I understand now. Indeed, the patches in e.g. 5.0 ports seem equivalent to what is now upstream (although not exactly identical). In your opinion, should upstream Boehm GC try to support pre-rthreads OpenBSD versions as well, or drop that and only support rthreads? (Or do the new patches work for both?) As far as I'm concerned it's not really worth supporting both, but this depends on their usual policies.. Any way, the new patches will have to be integrated to master. Would anyone like to take that job? If not, I'd like to try, although I don't know how long it would take for me. I don't want that job ;)
Re: rthread suspension
On Thu, Mar 21, 2013 at 11:43:15AM +, Stuart Henderson wrote:
On 2013/03/21 12:32, Taylan Ulrich B. wrote:
Stuart Henderson s...@spacehopper.org writes:
As I said, perhaps the uthread workarounds that we used to have
in the port got committed upstream and now need to be reverted?
i.e. _used_ to have, before the change to rthreads.
Oh sorry, I understand now. Indeed, the patches in e.g. 5.0 ports seem
equivalent to what is now upstream (although not exactly identical).
In your opinion, should upstream Boehm GC try to support pre-rthreads
OpenBSD versions as well, or drop that and only support rthreads? (Or do
the new patches work for both?)
As far as I'm concerned it's not really worth supporting both, but
this depends on their usual policies..
Upstream insisted on supporting both.
Any way, the new patches will have to be integrated to master. Would
anyone like to take that job? If not, I'd like to try, although I don't
know how long it would take for me.
I don't want that job ;)
AFAIK Kurt was talking about this recently and he was working with upstream
to have the patches integrated.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: mbuf(9) man page: update checksum flags
Lawrence Teo l...@openbsd.org wrote:
The checksum flags listed in the mbuf(9) man page do not match the ones
in mbuf.h. In addition, the m_pkthdr.csum variable name should be
m_pkthdr.csum_flags.
The following diff fixes both issues.
OK?
Okay, but while you're there, could you remove the /IPv4 from the
M_{TCP,UDP}_CSUM_IN_* descriptions? We also use this for TCP or
UDP over IPv6, e.g. on newer bge(4) chips.
I'm not sure there's a point in documenting the M_ICMP_CSUM_* flags.
They aren't actually implemented in the stack, few chipsets support
them, and I doubt there would be much benefit.
--
Christian naddy Weisgerber na...@mips.inka.de
Add ITE 8728 device to it(4)
It seems there's an ITE 8728 chip on my motherboard, and, it's showing some sensible information! :-) ok? it0 at isa0 port 0x2e/2: IT8728F rev 1, EC port 0x228 hw.sensors.it0.temp0=37.00 degC hw.sensors.it0.temp1=34.00 degC hw.sensors.it0.temp2=27.00 degC hw.sensors.it0.fan0=2020 RPM hw.sensors.it0.fan1=0 RPM hw.sensors.it0.fan2=0 RPM hw.sensors.it0.volt0=1.87 VDC (VCORE_A) hw.sensors.it0.volt1=1.95 VDC (VCORE_B) hw.sensors.it0.volt2=2.69 VDC (+3.3V) hw.sensors.it0.volt3=3.79 VDC (+5V) hw.sensors.it0.volt4=10.82 VDC (+12V) hw.sensors.it0.volt5=-1.75 VDC (-12V) hw.sensors.it0.volt6=0.62 VDC (-5V) hw.sensors.it0.volt7=3.76 VDC (+5VSB) hw.sensors.it0.volt8=2.05 VDC (VBAT) Index: dev/isa/it.c === RCS file: /cvs/src/sys/dev/isa/it.c,v retrieving revision 1.42 diff -u -p -r1.42 it.c --- dev/isa/it.c14 Dec 2012 13:17:29 - 1.42 +++ dev/isa/it.c21 Mar 2013 17:59:54 - @@ -168,6 +168,7 @@ it_match(struct device *parent, void *ma case IT_ID_8720: case IT_ID_8721: case IT_ID_8726: + case IT_ID_8728: case IT_ID_8772: /* get environment controller base address */ it_writereg(ia-ia_iot, ioh, IT_LDN, IT_EC_LDN); Index: dev/isa/itvar.h === RCS file: /cvs/src/sys/dev/isa/itvar.h,v retrieving revision 1.14 diff -u -p -r1.14 itvar.h --- dev/isa/itvar.h 14 Dec 2012 13:17:29 - 1.14 +++ dev/isa/itvar.h 21 Mar 2013 17:59:54 - @@ -47,6 +47,7 @@ #define IT_ID_8720 0x8720 #define IT_ID_8721 0x8721 #define IT_ID_8726 0x8726 +#define IT_ID_8728 0x8728 #define IT_ID_8772 0x8772 #define IT_CCR 0x02
[Patch] Update of repeat key patch, (was: Re: Weird wscons bug)
On Thu, Mar 21, 2013 at 06:05:11AM +, Miod Vallat wrote:
Excellent. Try setting the default, though:
# wsconsctl keyboard.repeat.deln.default=350
keyboard.repeat.deln.default - 200
In fact, if you check, whenever a user changes the normal value, the
default value changes too. So a normal, non-root user can change the
values for all of the VCs. Great.
No, that was a bug in wsconsctl where it would report the current repeat
rate as the default. Thanks for noticing it!
ARGH! I was looking for ages in the kernel source for a bug that didn't
exist :-)
Anyway, here are two more patches I've come up with. One is a simple
typo in a comment, the other is an updated repeat-key patch, which has
the following great features:
1. It actually works, and restores the user's custom settings, as you
pointed out that my original one didn't.
2. If you press command + repeat, it resets the rates to the defaults,
so if you accidently hose the console with wsconsctl keyboard.repeat.del1=1
it can be recovered easily.
--- wskbd.c.origTue Nov 15 04:15:52 2011
+++ wskbd.c.fixtypo Thu Mar 21 17:21:55 2013
@@ -269,7 +269,7 @@
#defineWSKBD_DEFAULT_KEYREPEAT_DEL1400 /* 400ms to start
repeating */
#endif
#ifndef WSKBD_DEFAULT_KEYREPEAT_DELN
-#defineWSKBD_DEFAULT_KEYREPEAT_DELN100 /* 100ms to between
repeats */
+#defineWSKBD_DEFAULT_KEYREPEAT_DELN100 /* 100ms between
repeats */
#endif
struct wskbd_keyrepeat_data wskbd_default_keyrepeat_data = {
--- wskbd.c.origTue Nov 15 04:15:52 2011
+++ wskbd.c Thu Mar 21 17:20:42 2013
@@ -272,12 +274,29 @@
#defineWSKBD_DEFAULT_KEYREPEAT_DELN100 /* 100ms to between
repeats */
#endif
+#ifndef WSKBD_KEY_KEYREPEAT_DEL1
+#defineWSKBD_KEY_KEYREPEAT_DEL125 /* 25ms to start
repeating */
+#endif
+#ifndef WSKBD_KEY_KEYREPEAT_DELN
+#defineWSKBD_KEY_KEYREPEAT_DELN25 /* 25ms between repeats
*/
+#endif
+
struct wskbd_keyrepeat_data wskbd_default_keyrepeat_data = {
WSKBD_KEYREPEAT_DOALL,
WSKBD_DEFAULT_KEYREPEAT_DEL1,
WSKBD_DEFAULT_KEYREPEAT_DELN,
};
+struct wskbd_keyrepeat_data wskbd_key_keyrepeat_data = {
+ WSKBD_KEYREPEAT_DOALL,
+ WSKBD_KEY_KEYREPEAT_DEL1,
+ WSKBD_KEY_KEYREPEAT_DELN,
+};
+
+struct wskbd_keyrepeat_data wskbd_store_keyrepeat_data = {
+ WSKBD_KEYREPEAT_DOALL, 0, 0,
+};
+
#if NWSMUX 0 || NWSDISPLAY 0
struct wssrcops wskbd_srcops = {
WSMUX_KBD,
@@ -1538,6 +1561,19 @@
if (sc != NULL kp-command != KS_voidSymbol)
iscommand = internal_command(sc, type, kp-command,
kp-group1[0]);
+
+ /* Check for repeat key */
+ if (kp-group1[0] == KS_Repeat type==WSCONS_EVENT_KEY_DOWN)
+ {
+ wskbd_store_keyrepeat_data = sc-sc_keyrepeat_data;
+ sc-sc_keyrepeat_data=wskbd_key_keyrepeat_data;
+ if (MOD_ONESET(sc-id, MOD_COMMAND) || MOD_ALLSET(sc-id, MOD_COMMAND1
| MOD_COMMAND2)) wskbd_store_keyrepeat_data = wskbd_default_keyrepeat_data;
+ }
+
+ if (kp-group1[0] == KS_Repeat type==WSCONS_EVENT_KEY_UP)
+ {
+ sc-sc_keyrepeat_data = wskbd_store_keyrepeat_data;
+ }
/* Now update modifiers */
switch (kp-group1[0]) {
--
Creamy
[Patch] Update Y2K bug workarounds in clock.c
All AMD64 systems should be Y2K compliant, so we can kill this code from
clock.c on this arch.
The i386 version currently only functions if the first boot after
Jan 1, 2000 is actually in the year 2000. Obviously now that we are in
2013, it's much more useful to allow the user to map
1900-1969 - 2000-2069 in the case that their BIOS doesn't allow years
past 1999 to be set directly.
The i386 version of the patch enables this behavior.
--- /usr/src/sys/arch/amd64/isa/clock.c.origTue Mar 19 22:20:59 2013
+++ /usr/src/sys/arch/amd64/isa/clock.c Thu Mar 21 18:57:36 2013
@@ -382,6 +382,8 @@
* check whether the CMOS layout is standard-like (ie, not PS/2-like),
* to be called at splclock()
*/
+
+/*
static int cmoscheck(void);
static int
cmoscheck(void)
@@ -390,70 +392,25 @@
unsigned short cksum = 0;
for (i = 0x10; i = 0x2d; i++)
- cksum += mc146818_read(NULL, i); /* XXX softc */
+ cksum += mc146818_read(NULL, i);
return (cksum == (mc146818_read(NULL, 0x2e) 8)
+ mc146818_read(NULL, 0x2f));
}
+*/
/*
- * patchable to control century byte handling:
- * 1: always update
- * -1: never touch
- * 0: try to figure out itself
- */
-int rtc_update_century = 0;
-
-/*
* Expand a two-digit year as read from the clock chip
* into full width.
- * Being here, deal with the CMOS century byte.
*/
-static int centb = NVRAM_CENTURY;
static int clock_expandyear(int);
static int
clock_expandyear(int clockyear)
{
- int s, clockcentury, cmoscentury;
+ int clockcentury;
clockcentury = (clockyear 70) ? 20 : 19;
clockyear += 100 * clockcentury;
-
- if (rtc_update_century 0)
- return (clockyear);
-
- s = splclock();
- if (cmoscheck())
- cmoscentury = mc146818_read(NULL, NVRAM_CENTURY);
- else
- cmoscentury = 0;
- splx(s);
- if (!cmoscentury) {
-#ifdef DIAGNOSTIC
- printf(clock: unknown CMOS layout\n);
-#endif
- return (clockyear);
- }
- cmoscentury = bcdtobin(cmoscentury);
-
- if (cmoscentury != clockcentury) {
- /* XXX note: saying century is 20 might confuse the naive. */
- printf(WARNING: NVRAM century is %d but RTC year is %d\n,
- cmoscentury, clockyear);
-
- /* Kludge to roll over century. */
- if ((rtc_update_century 0) ||
- ((cmoscentury == 19) (clockcentury == 20)
-(clockyear == 2000))) {
- printf(WARNING: Setting NVRAM century to %d\n,
- clockcentury);
- s = splclock();
- mc146818_write(NULL, centb, bintobcd(clockcentury));
- splx(s);
- }
- } else if (cmoscentury == 19 rtc_update_century == 0)
- rtc_update_century = 1; /* will update later in resettodr() */
-
return (clockyear);
}
@@ -560,7 +517,7 @@
{
mc_todregs rtclk;
struct clock_ymdhms dt;
- int century, diff, s;
+ int diff, s;
/*
* We might have been called by boot() due to a crash early
@@ -593,10 +550,6 @@
#endif
s = splclock();
rtcput(rtclk);
- if (rtc_update_century 0) {
- century = bintobcd(dt.dt_year / 100);
- mc146818_write(NULL, centb, century); /* XXX softc */
- }
splx(s);
}
--- clock.c.origThu Mar 21 19:12:36 2013
+++ clock.c Thu Mar 21 19:13:54 2013
@@ -543,8 +543,7 @@
/* Kludge to roll over century. */
if ((rtc_update_century 0) ||
- ((cmoscentury == 19) (clockcentury == 20)
-(clockyear == 2000))) {
+ ((cmoscentury == 19) (clockcentury == 20))) {
printf(WARNING: Setting NVRAM century to %d\n,
clockcentury);
s = splclock();
--
Creamy
[patch] libutil open/fcntl - O_CLOEXEC
patch to just call open() with O_CLOEXEC
Index: lib/libutil/check_expire.c
===
RCS file: /cvs/src/lib/libutil/check_expire.c,v
retrieving revision 1.8
diff -u -p -r1.8 check_expire.c
--- lib/libutil/check_expire.c 20 Apr 2004 23:21:23 - 1.8
+++ lib/libutil/check_expire.c 21 Mar 2013 20:19:56 -
@@ -173,8 +173,8 @@ pwd_update(const struct passwd *pwd, con
return(can't open passwd temp file);
}
- pfd = open(_PATH_MASTERPASSWD, O_RDONLY, 0);
- if (pfd 0 || fcntl(pfd, F_SETFD, 1) == -1) {
+ pfd = open(_PATH_MASTERPASSWD, O_RDONLY | O_CLOEXEC, 0);
+ if (pfd 0) {
pw_abort();
return(strerror(errno));
}
[patch] 1 - FD_CLOEXEC
patch to change 1 to FD_CLOEXEC. previous diff was OK'd by millert, but
here is an updated version.
Index: bin/systrace/openbsd-syscalls.c
===
RCS file: /cvs/src/bin/systrace/openbsd-syscalls.c,v
retrieving revision 1.41
diff -u -p -r1.41 openbsd-syscalls.c
--- bin/systrace/openbsd-syscalls.c 18 Sep 2011 23:24:14 - 1.41
+++ bin/systrace/openbsd-syscalls.c 21 Mar 2013 20:17:27 -
@@ -166,7 +166,7 @@ obsd_open(void)
goto out;
}
- if (fcntl(cfd, F_SETFD, 1) == -1)
+ if (fcntl(cfd, F_SETFD, FD_CLOEXEC) == -1)
warn(fcntl(F_SETFD));
out:
Index: lib/libc/db/btree/bt_open.c
===
RCS file: /cvs/src/lib/libc/db/btree/bt_open.c,v
retrieving revision 1.14
diff -u -p -r1.14 bt_open.c
--- lib/libc/db/btree/bt_open.c 17 Sep 2007 07:07:23 - 1.14
+++ lib/libc/db/btree/bt_open.c 21 Mar 2013 20:17:28 -
@@ -204,7 +204,7 @@ __bt_open(const char *fname, int flags,
F_SET(t, B_INMEM);
}
- if (fcntl(t-bt_fd, F_SETFD, 1) == -1)
+ if (fcntl(t-bt_fd, F_SETFD, FD_CLOEXEC) == -1)
goto err;
if (fstat(t-bt_fd, sb))
Index: lib/libc/db/hash/hash.c
===
RCS file: /cvs/src/lib/libc/db/hash/hash.c,v
retrieving revision 1.23
diff -u -p -r1.23 hash.c
--- lib/libc/db/hash/hash.c 2 Jul 2010 16:46:28 - 1.23
+++ lib/libc/db/hash/hash.c 21 Mar 2013 20:17:28 -
@@ -117,7 +117,7 @@ __hash_open(const char *file, int flags,
if (file) {
if ((hashp-fp = open(file, flags, mode)) == -1)
RETURN_ERROR(errno, error0);
- (void)fcntl(hashp-fp, F_SETFD, 1);
+ (void)fcntl(hashp-fp, F_SETFD, FD_CLOEXEC);
new_table = fstat(hashp-fp, statbuf) == 0
statbuf.st_size == 0 (flags O_ACCMODE) != O_RDONLY;
} else
Index: lib/libc/db/hash/hash_page.c
===
RCS file: /cvs/src/lib/libc/db/hash/hash_page.c,v
retrieving revision 1.19
diff -u -p -r1.19 hash_page.c
--- lib/libc/db/hash/hash_page.c11 May 2008 22:21:25 - 1.19
+++ lib/libc/db/hash/hash_page.c21 Mar 2013 20:17:28 -
@@ -858,7 +858,7 @@ open_temp(HTAB *hashp)
(void)sigprocmask(SIG_BLOCK, set, oset);
if ((hashp-fp = mkstemp(path)) != -1) {
(void)unlink(path);
- (void)fcntl(hashp-fp, F_SETFD, 1);
+ (void)fcntl(hashp-fp, F_SETFD, FD_CLOEXEC);
}
(void)sigprocmask(SIG_SETMASK, oset, (sigset_t *)NULL);
return (hashp-fp != -1 ? 0 : -1);
Index: lib/libc/gen/syslog_r.c
===
RCS file: /cvs/src/lib/libc/gen/syslog_r.c,v
retrieving revision 1.3
diff -u -p -r1.3 syslog_r.c
--- lib/libc/gen/syslog_r.c 30 May 2011 18:48:33 - 1.3
+++ lib/libc/gen/syslog_r.c 21 Mar 2013 20:17:28 -
@@ -279,7 +279,7 @@ connectlog_r(struct syslog_data *data)
if (data-log_file == -1) {
if ((data-log_file = socket(AF_UNIX, SOCK_DGRAM, 0)) == -1)
return;
- (void)fcntl(data-log_file, F_SETFD, 1);
+ (void)fcntl(data-log_file, F_SETFD, FD_CLOEXEC);
}
if (data-log_file != -1 !data-connected) {
memset(SyslogAddr, '\0', sizeof(SyslogAddr));
Index: lib/libc/yp/yp_bind.c
===
RCS file: /cvs/src/lib/libc/yp/yp_bind.c,v
retrieving revision 1.17
diff -u -p -r1.17 yp_bind.c
--- lib/libc/yp/yp_bind.c 5 Jun 2009 17:19:00 - 1.17
+++ lib/libc/yp/yp_bind.c 21 Mar 2013 20:17:28 -
@@ -242,7 +242,7 @@ gotdata:
ysd-dom_vers = -1;
goto again;
}
- if (fcntl(ysd-dom_socket, F_SETFD, 1) == -1)
+ if (fcntl(ysd-dom_socket, F_SETFD, FD_CLOEXEC) == -1)
perror(fcntl: F_SETFD);
if (new) {
Index: lib/libevent/signal.c
===
RCS file: /cvs/src/lib/libevent/signal.c,v
retrieving revision 1.15
diff -u -p -r1.15 signal.c
--- lib/libevent/signal.c 12 Jul 2010 18:03:38 - 1.15
+++ lib/libevent/signal.c 21 Mar 2013 20:17:28 -
@@ -85,7 +85,7 @@ evsignal_cb(int fd, short what, void *ar
#ifdef HAVE_SETFD
#define FD_CLOSEONEXEC(x) do { \
-if (fcntl(x, F_SETFD, 1) == -1) \
+if (fcntl(x, F_SETFD, FD_CLOEXEC) == -1) \
event_warn(fcntl(%d, F_SETFD), x); \
} while (0)
#else
Index: lib/libutil/passwd.c
===
RCS file: /cvs/src/lib/libutil/passwd.c,v
retrieving revision 1.49
diff -u -p -r1.49 passwd.c
---
Re: rthread suspension
On Thu, Mar 21, 2013 at 11:03, Taylan Ulrich B. wrote: I'm a GNU Guile 2.0 user, whose latest versions require latest versions of the Boehm garbage collector. This uses the functions pthread_suspend_np and pthread_resume_np, when built on OpenBSD, which don't exist in rthreads. Right. Early working version of librthread had them, but all the ports that needed these functions (boehm, java, ...) switched to using a system based on signals. Any general tips on how an application using the old API should be ported to the new one are also welcome. One question would be, should OpenBSD try to support functions from the old API on top of the new one (would patches in this nature be desirable), or should applications check for OpenBSD versions? Besides the existing boehm port, look at the history of the jdk port. We are not planning on adding the _np functions back. As the name implies, they are not portable, so it's better to come up with a different solution.
Re: i386 ports failures / new binutils
So it seems the bulk of additional amd64 failures are looking like this: /usr/bin/ld: MethodJIT.o: relocation R_X86_64_PC32 against `JaegerTrampolineReturn' can not be used when making a shared object; recompile with -fPIC On 2013/03/21 10:52, Stuart Henderson wrote: i386 package build is still running, but there are a few common failure modes I've picked up (and at least ffmpeg and gstreamer will have knocked out big chunks of the tree) so I think I'll send this out now. Mostly binutils-related but there may be other failures mixed in (this is the first full i386 build in about a month). - local symbol `environ' in /usr/lib/crt0.o is referenced by DSO multimedia/gstreamer*/plugins-base devel/jdk/1.7 - these look like problems with -Wl,--as-needed and inter library dependencies graphics/ffmpeg - ERROR: libvorbis not found sysutils/coreutils - /usr/local/lib/libintl.so.6.0: undefined reference to `libiconv_open' sysutils/upower - /usr/local/lib/libintl.so.6.0: undefined reference to `libiconv_open' - NLS disabled - no .mo files, pkg fails editors/vim (python flavours) - libpython2.7.so.0.0: undefined reference to `openpty' - Error: suffix or operands invalid for `mov' these are all movl with %eax and two-character registers, e.g. movl%fs, 8(%eax) movl8(%eax), %fs plan9/plan9port lang/io - www/chromium - OSError: [Errno 8] Exec format error - print/texlive/base - configure: error: cannot compute sizeof (wchar_t) (in configure tests of the bundled icu4c; the separate textproc/icu4c did build ok) - www/seamonkey - xpidl.IDLError: error: name 'nsIMsgIdentity' specified twice. - sysutils/gsmartcontrol - `.gnu.linkonce.t._Z11app_pcre_reRKSs' referenced in section `.gnu.linkonce.r._Z11app_pcre_reRKSs' of gsc_main_window.o: defined in discarded section `.gnu.linkonce.t._Z11app_pcre_reRKSs' of gsc_main_window.o
Re: i386 ports failures / new binutils
- local symbol `environ' in /usr/lib/crt0.o is referenced by DSO Hmm, that's odd. `environ' is a common and not declared as static or with any visibility attribute. Can you share the exact linking command which has triggered this error? - Error: suffix or operands invalid for `mov' these are all movl with %eax and two-character registers, e.g. movl%fs, 8(%eax) movl8(%eax), %fs This is actually not a bug. Segment registers ([cdefg]s) are 16-bit registers, so these should be used with `movw' instructions, not `movl'. Older gas was probably silently converting these to movw. - www/chromium - OSError: [Errno 8] Exec format error Please make the binary available to me offlist, as well as its linking command (or build log, whatever suits you). - sysutils/gsmartcontrol - `.gnu.linkonce.t._Z11app_pcre_reRKSs' referenced in section `.gnu.linkonce.r._Z11app_pcre_reRKSs' of gsc_main_window.o: defined in discarded section `.gnu.linkonce.t._Z11app_pcre_reRKSs' of gsc_main_window.o Can you send me your build log for this as well? Miod
Re: i386 ports failures / new binutils
Date: Thu, 21 Mar 2013 21:54:02 + From: Miod Vallat m...@online.fr - local symbol `environ' in /usr/lib/crt0.o is referenced by DSO Hmm, that's odd. `environ' is a common and not declared as static or with any visibility attribute. Can you share the exact linking command which has triggered this error? See the discussion on icb. Executive summary: Some ports are using version scripts to restrict the symbols exported from the executable. Since environ lives in crt0.o it becomes part of the executable. Since environ isn't listed in the version script it is forced to become local. The result is that libc.so can't use it anymore. The fix is probably to add environ and __progname to the appropriate version scripts.
Re: i386 ports failures / new binutils
On 2013/03/21 21:54, Miod Vallat wrote:
- local symbol `environ' in /usr/lib/crt0.o is referenced by DSO
Hmm, that's odd. `environ' is a common and not declared as static or
with any visibility attribute. Can you share the exact linking command
which has triggered this error?
Build log from this: http://junkpile.org/plugins-base.log
--version-script,./.libs/output-selector-test.ver comes from libtool and looks
like this:-
$ cat tests/icles/.libs/output-selector-test.ver
/* version script generated from
* output_selector_test-output-selector-test.o
* using regexp ^_*gst_plugin_desc.* */
{
local:
*;
};
- Error: suffix or operands invalid for `mov'
these are all movl with %eax and two-character registers, e.g.
movl%fs, 8(%eax)
movl8(%eax), %fs
This is actually not a bug. Segment registers ([cdefg]s) are 16-bit
registers, so these should be used with `movw' instructions, not `movl'.
Older gas was probably silently converting these to movw.
OK I will take care of these then.
- www/chromium - OSError: [Errno 8] Exec format error
Please make the binary available to me offlist, as well as its linking
command (or build log, whatever suits you).
I don't have the work directory, but will start another build of this.
http://junkpile.org/chromium.log
- sysutils/gsmartcontrol - `.gnu.linkonce.t._Z11app_pcre_reRKSs' referenced
in section `.gnu.linkonce.r._Z11app_pcre_reRKSs' of gsc_main_window.o:
defined in discarded section `.gnu.linkonce.t._Z11app_pcre_reRKSs' of
gsc_main_window.o
Can you send me your build log for this as well?
http://junkpile.org/gsmartcontrol.log
Miod
Thank you.
Re: i386 ports failures / new binutils
On 2013/03/21 21:54, Miod Vallat wrote: - www/chromium - OSError: [Errno 8] Exec format error Please make the binary available to me offlist, as well as its linking command (or build log, whatever suits you). Well this is very strange because if I run the program which generates the error message under ktrace -i, there is no ENOEXEC... python ../tools/protoc_wrapper/protoc_wrapper.py --include --protobuf /usr/obj/chromium-25.0.1364.173/chromium-25.0.1364.173/out/Release/obj/gen/protoc_out/chrome/common/metrics/proto/chrome_experiments.pb.h --proto-in-dir common/metrics/proto --proto-in-file chrome_experiments.proto --use-system-protobuf=0 -- /usr/obj/chromium-25.0.1364.173/chromium-25.0.1364.173/out/Release/protoc --cpp_out /usr/obj/chromium-25.0.1364.173/chromium-25.0.1364.173/out/Release/obj/gen/protoc_out/chrome/common/metrics/proto --python_out /usr/obj/chromium-25.0.1364.173/chromium-25.0.1364.173/out/Release/pyproto/chrome/common/metrics/proto - sysutils/gsmartcontrol - `.gnu.linkonce.t._Z11app_pcre_reRKSs' referenced in section `.gnu.linkonce.r._Z11app_pcre_reRKSs' of gsc_main_window.o: defined in discarded section `.gnu.linkonce.t._Z11app_pcre_reRKSs' of gsc_main_window.o Can you send me your build log for this as well? Miod
Re: LC_CTYPE for spanish speaking countries
Some ports in snapshot that include .po or .mo catalogs different to es_ES are (just listing few without repetition): davical es_AR es_MX es_VE gnomebaker es_CO, es_CR poedit es_PR zarafa es_CA The following packages have other localization files practically for every spanish speaking country (in the list I sent I have to add es_CA and es_US that are already there): concrete5, icinga-web, ocaml-camomile, p5-DateTime-Locale, py-babel, py-turbogears, zendframework Regarding the situtation with other languages, in /usr/src/share/locale/ctype/Makefile I find the following languages with countries pointing all of them to the same cmap definitions: * de_AT, de_CH and de_DE * fr_BE, fr_CA, fr_CH, fr_FR * it_CH, it_IT * nl_BE, nl_NL Why spanish is treated differently? Finally I don't live in Spain but in Colombia, so I should be able to use es_CO. H Best regards. On Thu, Mar 21, 2013 at 01:24:34AM +0100, Stefan Sperling wrote: On Wed, Mar 20, 2013 at 04:50:39PM -0430, Andres Perera wrote: On Wed, Mar 20, 2013 at 2:50 PM, Stefan Sperling s...@openbsd.org wrote: On Tue, Mar 19, 2013 at 06:44:59PM -0500, Vladimir Támara Patiño wrote: +#http://en.wikipedia.org/wiki/List_of_countries_where_Spanish_is_an_official_language +ES_COUNTRIES= AR BO CH CO CR CU DO EC ES GQ GT HN MX NI PA PE PR PY SV UY VE Sorry, but I don't really see the point of this. All these names are going to map to the same ctype definitions. That just clutters the /usr/share/locale directory. Why can't people just use es_ES? Because that's wrong. es_VE for ctype alone won't make a difference, but BSF isn't the same as Euro, is it? (hah) Date formats, etc., are different. And dictionary files (e.g., spellings for common cities) are also different. Yes, but unfortunately OpenBSD's locale implemnentation doesn't yet support much of what you mention above. AFAIK we currently only support the LC_CTYPE locale category. Please show me a real benefit of this change within the current implementation, or extend the implementation to create a benefit. Or you could identify some ports which install message files where adding new spanish locale variants will really make a difference. If such ports exist, I'm happy to add the corresponding locale variants. But I'm not going to bother making no-op changes to the system. -- Dios, gracias por tu amor infinito. -- Vladimir Támara Patiño. http://vtamara.pasosdeJesus.org/ http://www.pasosdejesus.org/dominio_publico_colombia.html
Re: mbuf(9) man page: update checksum flags
On Thu, Mar 21, 2013 at 04:13:35PM +, Christian Weisgerber wrote:
Lawrence Teo l...@openbsd.org wrote:
The checksum flags listed in the mbuf(9) man page do not match the ones
in mbuf.h. In addition, the m_pkthdr.csum variable name should be
m_pkthdr.csum_flags.
The following diff fixes both issues.
OK?
Okay, but while you're there, could you remove the /IPv4 from the
M_{TCP,UDP}_CSUM_IN_* descriptions? We also use this for TCP or
UDP over IPv6, e.g. on newer bge(4) chips.
I'm not sure there's a point in documenting the M_ICMP_CSUM_* flags.
They aren't actually implemented in the stack, few chipsets support
them, and I doubt there would be much benefit.
Thank you for your feedback. I have revised the diff to remove /IPv4
from the relevant descriptions, and it no longer includes the
M_ICMP_CSUM_* flags that I added earlier.
OK?
Index: mbuf.9
===
RCS file: /cvs/src/share/man/man9/mbuf.9,v
retrieving revision 1.59
diff -u -p -r1.59 mbuf.9
--- mbuf.9 3 Jan 2013 07:53:22 - 1.59
+++ mbuf.9 22 Mar 2013 01:37:06 -
@@ -302,28 +302,28 @@ buffer holding the data (size MHLEN).
.El
.Pp
The
-.Fa m_pkthdr.csum
+.Fa m_pkthdr.csum_flags
variable can take the following values:
.Pp
.Bl -tag -compact -offset indent -width XX
.It Dv M_IPV4_CSUM_OUT
IPv4 checksum needed.
-.It Dv M_TCPV4_CSUM_OUT
+.It Dv M_TCP_CSUM_OUT
TCP checksum needed.
-.It Dv M_UDPV4_CSUM_OUT
+.It Dv M_UDP_CSUM_OUT
UDP checksum needed.
.It Dv M_IPV4_CSUM_IN_OK
IPv4 checksum verified.
.It Dv M_IPV4_CSUM_IN_BAD
IPv4 checksum bad.
.It Dv M_TCP_CSUM_IN_OK
-TCP/IPv4 checksum verified.
+TCP checksum verified.
.It Dv M_TCP_CSUM_IN_BAD
-TCP/IPv4 checksum bad.
+TCP checksum bad.
.It Dv M_UDP_CSUM_IN_OK
-UDP/IPv4 checksum verified.
+UDP checksum verified.
.It Dv M_UDP_CSUM_IN_BAD
-UDP/IPv4 checksum bad.
+UDP checksum bad.
.El
.Pp
When only M_EXT flag is set, an external storage buffer is being used to
[patch] fsdb cleanup
use %u for unsigned (ino_t).
Index: fsdb.c
===
RCS file: /cvs/src/sbin/fsdb/fsdb.c,v
retrieving revision 1.23
diff -u -p -r1.23 fsdb.c
--- fsdb.c 27 Oct 2009 23:59:33 - 1.23
+++ fsdb.c 22 Mar 2013 01:49:27 -
@@ -202,7 +202,7 @@ prompt(EditLine *el)
{
static char pstring[64];
- snprintf(pstring, sizeof(pstring), fsdb (inum: %d) , curinum);
+ snprintf(pstring, sizeof(pstring), fsdb (inum: %u) , curinum);
return pstring;
}
@@ -285,7 +285,7 @@ static ino_t ocurrent;
#define GETINUM(ac,inum)inum = strtoul(argv[ac], cp, 0); \
if (inum ROOTINO || inum maxino || cp == argv[ac] || *cp != '\0' )
{ \
- printf(inode %d out of range; range is [%d,%d]\n, \
+ printf(inode %u out of range; range is [%u,%u]\n, \
inum, ROOTINO, maxino); \
return 1; \
}
@@ -346,7 +346,7 @@ CMDFUNCSTART(uplink)
if (!checkactive())
return 1;
DIP_SET(curinode, di_nlink, DIP(curinode, di_nlink) + 1);
- printf(inode %d link count now %d\n, curinum, DIP(curinode,
di_nlink));
+ printf(inode %u link count now %d\n, curinum, DIP(curinode,
di_nlink));
inodirty();
return 0;
}
@@ -356,7 +356,7 @@ CMDFUNCSTART(downlink)
if (!checkactive())
return 1;
DIP_SET(curinode, di_nlink, DIP(curinode, di_nlink) - 1);
- printf(inode %d link count now %d\n, curinum, DIP(curinode,
di_nlink));
+ printf(inode %u link count now %d\n, curinum, DIP(curinode,
di_nlink));
inodirty();
return 0;
}
@@ -386,7 +386,7 @@ scannames(struct inodesc *idesc)
{
struct direct *dirp = idesc-id_dirp;
- printf(slot %d ino %d reclen %d: %s, `%.*s'\n,
+ printf(slot %d ino %u reclen %u: %s, `%.*s'\n,
slot++, dirp-d_ino, dirp-d_reclen, typename[dirp-d_type],
dirp-d_namlen, dirp-d_name);
return (KEEPON);
@@ -474,7 +474,7 @@ CMDFUNCSTART(ln)
return 1;
rval = makeentry(curinum, inum, argv[2]);
if (rval)
- printf(Ino %d entered as `%s'\n, inum, argv[2]);
+ printf(Ino %u entered as `%s'\n, inum, argv[2]);
else
printf(could not enter name? weird.\n);
curinode = ginode(curinum);
Index: fsdbutil.c
===
RCS file: /cvs/src/sbin/fsdb/fsdbutil.c,v
retrieving revision 1.14
diff -u -p -r1.14 fsdbutil.c
--- fsdbutil.c 27 Oct 2009 23:59:33 - 1.14
+++ fsdbutil.c 22 Mar 2013 01:49:27 -
@@ -193,10 +193,10 @@ printactive(void)
printstat(current inode, curinum, curinode);
break;
case 0:
- printf(current inode %d: unallocated inode\n, curinum);
+ printf(current inode %u: unallocated inode\n, curinum);
break;
default:
- printf(current inode %d: screwy itype 0%o (mode 0%o)?\n,
+ printf(current inode %u: screwy itype 0%o (mode 0%o)?\n,
curinum, DIP(curinode, di_mode) IFMT,
DIP(curinode, di_mode));
break;
Re: LC_CTYPE for spanish speaking countries
On Thu, Mar 21, 2013 at 06:59:44PM -0500, Vladimir Támara Patiño wrote: Regarding the situtation with other languages, in /usr/src/share/locale/ctype/Makefile I find the following languages with countries pointing all of them to the same cmap definitions: * de_AT, de_CH and de_DE Taking this as an example, I do think that one German locale would be enough, given that all these language variants use the exact same character sets and written language looks the same everywhere (to me, as a native speaker). There might be other differences, but these don't matter for OpenBSD right now. OpenBSD's locale feature set is so limited that making a distinction between Austria, Switzerland, and Germany really makes no sense. The only locale-specific things in OpenBSD are: - the available character set - message files for programs from ports (base system has very few translations) So, in the case of German, the result of setting any of these de_* locales is the same in practice. I doubt anyone goes through the hassle of maintaining separate translations for 3 German-speaking countries. There will usually be one translation and it gets installed as de_DE, de_AT, and de_CH. On non-OpenBSD systems, people might prefer de_CH over de_DE for other reasons, so it makes sense to provide this locale. But on OpenBSD it doesn't make much sense yet. I believe we need more than one Spanish locale, because I know that spoken and written Spanish differs between Europe and South America in several ways. Unfortunately I don't know any Spanish so I can't really judge how big these difference are. Do we really need _21_ locales for Spanish, like in your diff? Wouldn't adding one or two locales for South-American dialects of Spanish be enough to cover these differences, at least where it makes a difference in terms of OpenBSD's limited functionality, and where it affects a significant chunk of ports? * fr_BE, fr_CA, fr_CH, fr_FR * it_CH, it_IT * nl_BE, nl_NL Why spanish is treated differently? No reason. There was simply nobody so far who was bothered by the lack of other Spanish locales. You are the first person to complain about this. That's all. Finally I don't live in Spain but in Colombia, so I should be able to use es_CO. No offence, but to me, the name of a locale is just... a name. Let's try to make useful functional changes to the system. Adding locales for purely patriotic reasons seems like a waste of time to me. Please tell me more about the functional reasons you have for adding 21 additional locale files, and why adding less than 21 would not suffice.
Re: rthread suspension
On Thursday 21 March 2013 7:47:34 am Brad Smith wrote:
On Thu, Mar 21, 2013 at 11:43:15AM +, Stuart Henderson wrote:
On 2013/03/21 12:32, Taylan Ulrich B. wrote:
Stuart Henderson s...@spacehopper.org writes:
As I said, perhaps the uthread workarounds that we used to have
in the port got committed upstream and now need to be reverted?
i.e. _used_ to have, before the change to rthreads.
Oh sorry, I understand now. Indeed, the patches in e.g. 5.0 ports seem
equivalent to what is now upstream (although not exactly identical).
In your opinion, should upstream Boehm GC try to support pre-rthreads
OpenBSD versions as well, or drop that and only support rthreads? (Or do
the new patches work for both?)
As far as I'm concerned it's not really worth supporting both, but
this depends on their usual policies..
Upstream insisted on supporting both.
Any way, the new patches will have to be integrated to master. Would
anyone like to take that job? If not, I'd like to try, although I don't
know how long it would take for me.
I don't want that job ;)
AFAIK Kurt was talking about this recently and he was working with upstream
to have the patches integrated.
I stalled on submitting them with upstream. I ran into a snafu. However, I
do have an update for boehm-gc that can be tested. There's one i386
machine in my cluster that doesn't behave which is one of the reasons
I haven't moved this forward yet. It is on my todo list which I'm chipping
away at little by little.
-Kurt
Index: Makefile
===
RCS file: /cvs/ports/devel/boehm-gc/Makefile,v
retrieving revision 1.48
diff -u -p -r1.48 Makefile
--- Makefile 11 Mar 2013 10:50:01 - 1.48
+++ Makefile 22 Mar 2013 02:59:26 -
@@ -3,12 +3,12 @@
COMMENT-main= garbage collection and memory leak detection for C and C++
COMMENT-atomic= access to hardware provided atomic memory operations
-VERSION= 7.0
+VERSION= 7.2d
DISTNAME= gc-${VERSION}
-PKGNAME-atomic= libatomic_ops-1.2
+PKGNAME-atomic= libatomic_ops-${VERSION}
PKGNAME-main= boehm-gc-${VERSION}
-REVISION= 7
+WRKDIST= ${WRKDIR}/gc-7.2
MULTI_PACKAGES= -main -atomic
SHARED_LIBS += gc 3.0 # .1.2
@@ -27,7 +27,7 @@ NOT_FOR_ARCHS= m68k m88k vax mips64 mips
PERMIT_PACKAGE_CDROM= Yes
-WANTLIB += pthread
+WANTLIB-main += pthread
MAKE_ENV= CP=cp \
INSTALL_DATA=${INSTALL_DATA} \
@@ -36,7 +36,7 @@ MAKE_ENV= CP=cp \
USE_LIBTOOL= Yes
USE_GROFF = Yes
-AUTOCONF_VERSION= 2.61
+AUTOCONF_VERSION= 2.68
CONFIGURE_STYLE= autoconf no-autoheader
CONFIGURE_ARGS= ${CONFIGURE_SHARED} \
Index: distinfo
===
RCS file: /cvs/ports/devel/boehm-gc/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- distinfo 14 Jul 2007 22:16:16 - 1.7
+++ distinfo 22 Mar 2013 02:59:26 -
@@ -1,5 +1,2 @@
-MD5 (gc-7.0.tar.gz) = NkXM9fMuuyfZmyew0p6cOA==
-RMD160 (gc-7.0.tar.gz) = SRLiWQ3YISvr7rHjJQZ2LKMdAIg=
-SHA1 (gc-7.0.tar.gz) = ZX2EtwKlcvilENLChXim26rT/tI=
-SHA256 (gc-7.0.tar.gz) = 0grG6Tm4J3BDS3bk99wYpAmdUH609CpdOtdGJQwBHls=
-SIZE (gc-7.0.tar.gz) = 1072682
+SHA256 (gc-7.2d.tar.gz) = 2f4K6GUNQ3RqSL+zlMqwGjGfOAnO4Z+OvRaqmFtRHF4=
+SIZE (gc-7.2d.tar.gz) = 1263064
Index: patches/patch-bdw-gc_pc_in
===
RCS file: patches/patch-bdw-gc_pc_in
diff -N patches/patch-bdw-gc_pc_in
--- patches/patch-bdw-gc_pc_in 9 Dec 2009 20:36:49 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,10 +0,0 @@
-$OpenBSD: patch-bdw-gc_pc_in,v 1.1 2009/12/09 20:36:49 sthen Exp $
bdw-gc.pc.in.orig Mon Dec 7 10:57:34 2009
-+++ bdw-gc.pc.in Mon Dec 7 10:57:46 2009
-@@ -6,5 +6,5 @@ includedir=@includedir@
- Name: Boehm-Demers-Weiser Conservative Garbage Collector
- Description: A garbage collector for C and C++
- Version: @PACKAGE_VERSION@
--Libs: -L${libdir} -lgc
-+Libs: -L${libdir} -lgc -pthread
- Cflags: -I${includedir}
Index: patches/patch-configure_ac
===
RCS file: patches/patch-configure_ac
diff -N patches/patch-configure_ac
--- patches/patch-configure_ac 22 Feb 2012 12:31:42 - 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,25 +0,0 @@
-$OpenBSD: patch-configure_ac,v 1.2 2012/02/22 12:31:42 kurt Exp $
configure.ac.orig Sat Jun 30 11:40:15 2007
-+++ configure.ac Sun Feb 19 12:57:00 2012
-@@ -113,6 +113,11 @@ case $THREADS in
- *-*-hpux10*)
- AC_MSG_WARN(Only HP-UX 11 POSIX threads are supported.)
- ;;
-+ *-*-openbsd*)
-+ AC_DEFINE(GC_OPENBSD_THREADS)
-+ THREADDLLIBS=-pthread
-+ INCLUDES=$INCLUDES -pthread
-+ ;;
- *-*-freebsd*)
- AC_MSG_WARN(FreeBSD does not yet fully support threads with Boehm GC.)
- AC_DEFINE(GC_FREEBSD_THREADS)
-@@ -394,6 +399,9 @@ case $host in
- ;;
- sparc-*-netbsd*)
- machdep=mach_dep.lo sparc_netbsd_mach_dep.lo
-+;;
-+ sparc*-*-openbsd*)
