Re: long long time_t for /bin/date
On Sat, 19 Oct 2013 20:07:59 -0700, Philip Guenther wrote: On Sat, Oct 19, 2013 at 7:34 PM, J Drivdal x...@rivu.net wrote: /bin/date -r stops at 2038 with i386. File: src/bin/date/date.c Thanks. Committed Philip Guenther Wow! I knew about that ages ago but I assumed that Theo had decided that there was a reason to let it grind to a halt - to wit: getting the attention of people to the need to start working on the Y2K38 bug. When I wanted to demonstrate the result of not fixing it, I would do something like: # date -u -r -2147483648 to get the Dec 13 20:45:52 GMT 1901 result. NB for the superstitious flock, that's a Friday. 8-) R/ *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
Re: partial xlocale(3) port from FreeBSD
On Sat, Oct 19, 2013 at 09:26:47PM -0700, Philip Guenther wrote:
On Tue, 15 Oct 2013, Martin Pelikan wrote:
Obviously, our locale support still sucks, this patch is mostly
providing the API for filling the blanks later.
Which blanks exactly? Locale features we don't have, such as collation?
Locale support sucks because most base applications don't make use of it.
Adding more stuff to libc won't fix that.
How much did the ramdisks grow by when you built release with this?
Having just freed up a bunch of space on the ramdisks, I'll be pissed if
we squander it all immediately.
The only locale code that belongs on the ramdisks is in
/usr/src/distrib/special/libstubs/{mbrtowc_sb.c,setlocale}.c.
These are required for vfprintf(). Anything else should not
be built into the ramdisk to avoid pulling in citrus as a dependency.
I'm not very excited about xlocale. If the only goal here is an API
shim to compile a C++ library, can't we put the shim somewhere else
than libc? Like the misc/libutf8 port we used to have?
Re: Add Xbox 360 Controller USB support
Hi Jeremy,
On 18/10/13(Fri) 09:11, Jeremy Evans wrote:
This was originally submitted by Joe Gidi in November 2010, based on a
FreeBSD commit by Ed Schouten from back in December 2005. See
http://marc.info/?l=openbsd-techm=128924886803756w=2 for previous
thread. The only comment was from tedu@, that SMALL_KERNEL should be
added, which I've done but I'm not sure correctly.
Tested on amd64 using usbhidctl and some SDL-based emulators (mednafen,
snes9x-gtk, desmume). The controller works fine except that the
directional pad is not processed as a hat but as a series of buttons
(that usbhidctl sees but SDL seems not to recognize). Also, the bottom
L/R triggers are axes instead of buttons.
I've built a release with this, and checked that the amd64 floppy
still fits.
Good stuff, some comments below.
Index: uhidev.c
===
RCS file: /cvs/src/sys/dev/usb/uhidev.c,v
retrieving revision 1.46
diff -u -p -r1.46 uhidev.c
--- uhidev.c 20 Sep 2013 15:34:50 - 1.46
+++ uhidev.c 17 Oct 2013 23:32:55 -
@@ -55,8 +55,11 @@
#include dev/usb/uhidev.h
-/* Report descriptor for broken Wacom Graphire */
+/* Replacement report descriptors for devices shipped with broken ones */
#include dev/usb/ugraphire_rdesc.h
+#ifndef SMALL_KERNEL
+#include dev/usb/uxb360gp_rdesc.h
+#endif /* !SMALL_KERNEL */
Can you also include the ugraphire header in the #ifndef block, since we
don't include ums(4) in the ramdisk, this will same even more space!
#ifdef UHIDEV_DEBUG
#define DPRINTF(x) do { if (uhidevdebug) printf x; } while (0)
@@ -99,8 +102,17 @@ uhidev_match(struct device *parent, void
if (uaa-iface == NULL)
return (UMATCH_NONE);
id = usbd_get_interface_descriptor(uaa-iface);
- if (id == NULL || id-bInterfaceClass != UICLASS_HID)
- return (UMATCH_NONE);
+if (id == NULL)
+return (UMATCH_NONE);
+if (id-bInterfaceClass != UICLASS_HID) {
+#ifndef SMALL_KERNEL
+/* The Xbox 360 gamepad doesn't use the HID class. */
+if (id-bInterfaceClass != UICLASS_VENDOR ||
+id-bInterfaceSubClass != UISUBCLASS_XBOX360_CONTROLLER
||
+id-bInterfaceProtocol != UIPROTO_XBOX360_GAMEPAD)
+#endif /* !SMALL_KERNEL */
I would prefer to add another quirk to usbd_quirks something like
UQ_FORCE_HID, rather than hardcoding the device id here.
+return (UMATCH_NONE);
+}
if (usbd_get_quirks(uaa-device)-uq_flags UQ_BAD_HID)
return (UMATCH_NONE);
if (uaa-matchlvl)
@@ -200,7 +212,16 @@ uhidev_attach(struct device *parent, str
/* Keep descriptor */
break;
}
+#ifndef SMALL_KERNEL
+ } else if (id-bInterfaceClass == UICLASS_VENDOR
+ id-bInterfaceSubClass == UISUBCLASS_XBOX360_CONTROLLER
+ id-bInterfaceProtocol == UIPROTO_XBOX360_GAMEPAD) {
+ /* The Xbox 360 gamepad has no report descriptor. */
+ size = sizeof uhid_xb360gp_report_descr;
+ descptr = uhid_xb360gp_report_descr;
+#endif /* !SMALL_KERNEL */
Can you merge this chunk into the switch just before since it will also
be #ifndef, and also use the uaa argument like for wacom devices?
}
+
if (descptr) {
desc = malloc(size, M_USBDEV, M_NOWAIT);
Index: usb.h
===
RCS file: /cvs/src/sys/dev/usb/usb.h,v
retrieving revision 1.44
diff -u -p -r1.44 usb.h
--- usb.h 17 Apr 2013 11:53:10 - 1.44
+++ usb.h 17 Oct 2013 18:11:59 -
@@ -491,7 +491,8 @@ typedef struct {
#define UIPROTO_IRDA0
#define UICLASS_VENDOR 0xff
-
+#define UISUBCLASS_XBOX360_CONTROLLER 0x5d
+#define UIPROTO_XBOX360_GAMEPAD 0x01
I am not a big fan of having vendor/device specific defines in usb.h
which should be a generic header that's also included by userland.
#define USB_HUB_MAX_DEPTH 5
Index: uxb360gp_rdesc.h
===
RCS file: uxb360gp_rdesc.h
diff -N uxb360gp_rdesc.h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ uxb360gp_rdesc.h 17 Oct 2013 18:23:56 -
@@ -0,0 +1,126 @@
+/*-
+ * Copyright (c) 2005 Ed Schouten e...@freebsd.org
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other
Wrong rights for ELF interpreters
Hi, when the kernel loads an ELF binary, it will also load its interpreter. The kernel checks the rights of the interpreter, that way: if ((error = VOP_ACCESS(vp, VREAD, p-p_ucred, p)) != 0) goto bad1; It should check with VEXEC instead of VREAD. Interpreters get executed, so they have to be executable; a read-only interpreter shouldn't be loaded by the kernel. Index: exec_elf.c === RCS file: /cvs/src/sys/kern/exec_elf.c,v retrieving revision 1.93 diff -u -r1.93 exec_elf.c --- exec_elf.c 4 Jul 2013 17:37:05 - 1.93 +++ exec_elf.c 7 Oct 2013 19:03:33 - @@ -345,7 +345,7 @@ error = EACCES; goto bad; } - if ((error = VOP_ACCESS(vp, VREAD, p-p_ucred, p)) != 0) + if ((error = VOP_ACCESS(vp, VEXEC, p-p_ucred, p)) != 0) goto bad1; if ((error = ELFNAME(read_from)(p, nd.ni_vp, 0, (caddr_t)eh, sizeof(eh))) != 0) Ok/Comments?
Re: Add Xbox 360 Controller USB support
On Fri, 18 Oct 2013 09:11:05 -0700 Jeremy Evans jer...@openbsd.org wrote: Tested on amd64 using usbhidctl and some SDL-based emulators (mednafen, snes9x-gtk, desmume). The controller works fine except that the directional pad is not processed as a hat but as a series of buttons (that usbhidctl sees but SDL seems not to recognize). Also, the bottom L/R triggers are axes instead of buttons. L/R triggers being axes is the correct behavior, this is for games like Forza where how hard you hold down the triggers controls how hard you accelerate/brake.
Re: Wrong rights for ELF interpreters
when the kernel loads an ELF binary, it will also load its interpreter. The kernel checks the rights of the interpreter, that way: if ((error = VOP_ACCESS(vp, VREAD, p-p_ucred, p)) != 0) goto bad1; It should check with VEXEC instead of VREAD. Interpreters get executed, so they have to be executable; a read-only interpreter shouldn't be loaded by the kernel. I am not sure I agree on this.
Re: Wrong rights for ELF interpreters
Le 20/10/2013 16:53, Theo de Raadt a écrit : when the kernel loads an ELF binary, it will also load its interpreter. The kernel checks the rights of the interpreter, that way: if ((error = VOP_ACCESS(vp, VREAD, p-p_ucred, p)) != 0) goto bad1; It should check with VEXEC instead of VREAD. Interpreters get executed, so they have to be executable; a read-only interpreter shouldn't be loaded by the kernel. I am not sure I agree on this. Why?
Re: Wrong rights for ELF interpreters
Le 20/10/2013 16:53, Theo de Raadt a écrit : when the kernel loads an ELF binary, it will also load its interpreter. The kernel checks the rights of the interpreter, that way: if ((error = VOP_ACCESS(vp, VREAD, p-p_ucred, p)) != 0) goto bad1; It should check with VEXEC instead of VREAD. Interpreters get executed, so they have to be executable; a read-only interpreter shouldn't be loaded by the kernel. I am not sure I agree on this. Why? VEXEC is used in other cases to insist on a filesystem permission, for instance, when supplying a path for execve(). The interpreter is not a path supplied to execve.
Re: Wrong rights for ELF interpreters
On Sun, Oct 20, 2013 at 18:00, Maxime Villard wrote: It should check with VEXEC instead of VREAD. Interpreters get executed, so they have to be executable; a read-only interpreter shouldn't be loaded by the kernel. I am not sure I agree on this. Why? How is loading the interpreter different than loading a shared library? Libraries are executed, too.
Re: Wrong rights for ELF interpreters
Le 20/10/2013 18:05, Theo de Raadt a écrit : Le 20/10/2013 16:53, Theo de Raadt a écrit : when the kernel loads an ELF binary, it will also load its interpreter. The kernel checks the rights of the interpreter, that way: if ((error = VOP_ACCESS(vp, VREAD, p-p_ucred, p)) != 0) goto bad1; It should check with VEXEC instead of VREAD. Interpreters get executed, so they have to be executable; a read-only interpreter shouldn't be loaded by the kernel. I am not sure I agree on this. Why? VEXEC is used in other cases to insist on a filesystem permission, for instance, when supplying a path for execve(). The interpreter is not a path supplied to execve. Indeed, the interpreter is not passed to execve. That's why I used 'get executed' instead of 'are executed' though the difference might not be clear. The kernel loads the interpreter, and the code of that interpreter gets executed. So, actually, it plays as an executable. And as long as code gets executed from it, it should have +x rights. Shouldn't it?
Re: Add Xbox 360 Controller USB support
On 10/20 03:52, Martin Pieuchot wrote:
Hi Jeremy,
On 18/10/13(Fri) 09:11, Jeremy Evans wrote:
This was originally submitted by Joe Gidi in November 2010, based on a
FreeBSD commit by Ed Schouten from back in December 2005. See
http://marc.info/?l=openbsd-techm=128924886803756w=2 for previous
thread. The only comment was from tedu@, that SMALL_KERNEL should be
added, which I've done but I'm not sure correctly.
Tested on amd64 using usbhidctl and some SDL-based emulators (mednafen,
snes9x-gtk, desmume). The controller works fine except that the
directional pad is not processed as a hat but as a series of buttons
(that usbhidctl sees but SDL seems not to recognize). Also, the bottom
L/R triggers are axes instead of buttons.
I've built a release with this, and checked that the amd64 floppy
still fits.
Good stuff, some comments below.
Martin,
Thanks for responding. Here's a new diff that incorporates most of your
suggestions. Unfortunately, using the existing quirks infrastructure
doesn't work correctly, because the quirks API is based on device
manufacturer and vendor, and matching on that instead of interface
subclass and protocol appears to not work correctly. When you plug in
the controller with my original diff and the first diff below, you get:
uhidev0 at uhub3 port 3 configuration 1 interface 0 \M-)Microsoft Corporation
Controller rev 2.00/1.10 addr 2
uhidev0: iclass 255/93
uhid0 at uhidev0: input=20, output=0, feature=0
ugen0 at uhub3 port 3 configuration 1 \M-)Microsoft Corporation Controller
rev 2.00/1.10 addr 2
As you can see, the controller shows up as both a uhid and a ugen.
With the second diff below, when you plugin the controller, it
attaches as follows:
uhidev0 at uhub3 port 3 configuration 1 interface 0 \M-)Microsoft Corporation
Controller rev 2.00/1.10 addr 2
uhidev0: iclass 255/93
uhid0 at uhidev0: input=20, output=0, feature=0
uhidev1 at uhub3 port 3 configuration 1 interface 1 \M-)Microsoft Corporation
Controller rev 2.00/1.10 addr 2
uhidev1: iclass 255/93
uhid1 at uhidev1: input=20, output=0, feature=0
uhidev2 at uhub3 port 3 configuration 1 interface 2 \M-)Microsoft Corporation
Controller rev 2.00/1.10 addr 2
uhidev2: iclass 255/93
uhid2 at uhidev2: input=20, output=0, feature=0
uhidev3 at uhub3 port 3 configuration 1 interface 3 \M-)Microsoft Corporation
Controller rev 2.00/1.10 addr 2
uhidev3: no input interrupt endpoint
In this case uhid0 appears to work, but uhid1 and uhid2 do not:
$ usbhidctl -f 1 -a
usbhidctl: USB_GET_REPORT (probably not supported by device): Input/output error
Anyway, let me know what you think about the first diff, or if I'm doing
something wrong with the second diff that is causing it to attach
multiple times.
Thanks,
Jeremy
Working diff:
Index: uhidev.c
===
RCS file: /cvs/src/sys/dev/usb/uhidev.c,v
retrieving revision 1.46
diff -u -p -r1.46 uhidev.c
--- uhidev.c20 Sep 2013 15:34:50 - 1.46
+++ uhidev.c20 Oct 2013 18:23:37 -
@@ -55,8 +55,13 @@
#include dev/usb/uhidev.h
-/* Report descriptor for broken Wacom Graphire */
+#ifndef SMALL_KERNEL
+/* Replacement report descriptors for devices shipped with broken ones */
#include dev/usb/ugraphire_rdesc.h
+#include dev/usb/uxb360gp_rdesc.h
+#defineUISUBCLASS_XBOX360_CONTROLLER 0x5d
+#defineUIPROTO_XBOX360_GAMEPAD 0x01
+#endif /* !SMALL_KERNEL */
#ifdef UHIDEV_DEBUG
#define DPRINTF(x) do { if (uhidevdebug) printf x; } while (0)
@@ -99,8 +104,17 @@ uhidev_match(struct device *parent, void
if (uaa-iface == NULL)
return (UMATCH_NONE);
id = usbd_get_interface_descriptor(uaa-iface);
- if (id == NULL || id-bInterfaceClass != UICLASS_HID)
- return (UMATCH_NONE);
+if (id == NULL)
+return (UMATCH_NONE);
+if (id-bInterfaceClass != UICLASS_HID) {
+#ifndef SMALL_KERNEL
+/* The Xbox 360 gamepad doesn't use the HID class. */
+if (id-bInterfaceClass != UICLASS_VENDOR ||
+id-bInterfaceSubClass != UISUBCLASS_XBOX360_CONTROLLER ||
+id-bInterfaceProtocol != UIPROTO_XBOX360_GAMEPAD)
+#endif /* !SMALL_KERNEL */
+return (UMATCH_NONE);
+}
if (usbd_get_quirks(uaa-device)-uq_flags UQ_BAD_HID)
return (UMATCH_NONE);
if (uaa-matchlvl)
@@ -180,6 +194,7 @@ uhidev_attach(struct device *parent, str
/* XXX need to extend this */
descptr = NULL;
+#ifndef SMALL_KERNEL
if (uaa-vendor == USB_VENDOR_WACOM) {
static uByte reportbuf[] = {2, 2, 2};
@@ -200,7 +215,15 @@ uhidev_attach(struct device *parent, str
/* Keep descriptor */
break;
}
+ } else if (id-bInterfaceClass == UICLASS_VENDOR
+ id-bInterfaceSubClass ==
Re: Wrong rights for ELF interpreters
It should check with VEXEC instead of VREAD. Interpreters get executed, so they have to be executable; a read-only interpreter shouldn't be loaded by the kernel. I am not sure I agree on this. Why? How is loading the interpreter different than loading a shared library? Libraries are executed, too. good lord. chmod a+x /usr/lib/lib*.so.*.* It is silly.
Re: Wrong rights for ELF interpreters
Le 20/10/2013 18:05, Theo de Raadt a écrit : Le 20/10/2013 16:53, Theo de Raadt a écrit : when the kernel loads an ELF binary, it will also load its interpreter. The kernel checks the rights of the interpreter, that way: if ((error = VOP_ACCESS(vp, VREAD, p-p_ucred, p)) != 0) goto bad1; It should check with VEXEC instead of VREAD. Interpreters get executed, so they have to be executable; a read-only interpreter shouldn't be loaded by the kernel. I am not sure I agree on this. Why? VEXEC is used in other cases to insist on a filesystem permission, for instance, when supplying a path for execve(). The interpreter is not a path supplied to execve. Indeed, the interpreter is not passed to execve. That's why I used 'get executed' instead of 'are executed' though the difference might not be clear. The kernel loads the interpreter, and the code of that interpreter gets executed. So, actually, it plays as an executable. And as long as code gets executed from it, it should have +x rights. Shouldn't it? Absolutely not, because then someone can try to run execve on it. You are not thinking clearly.
PATCH: Remove #define DEBUG in octeon kernel source
Remove #define DEBUG in octeon kernel. Breaks build if building the kernel with DEBUG set in config. Index: octeon/machdep.c === RCS file: /cvs/src/sys/arch/octeon/octeon/machdep.c,v retrieving revision 1.41 diff -u -b -w -p -r1.41 machdep.c --- octeon/machdep.c28 Sep 2013 12:40:31 - 1.41 +++ octeon/machdep.c20 Oct 2013 19:37:25 - @@ -393,7 +393,6 @@ mips_init(__register_t a0, __register_t consinit(); printf(Initial setup done, switching console.\n); -#define DEBUG #ifdef DEBUG #define DUMP_BOOT_DESC(field, format) \ printf(boot_desc- #field : #format \n, boot_desc-field)
unlimited HFSC v3: more readable, less hacks
Hopefully the third time does the charm.
The previous union approach to altq/newq bits was wrong, because
switching back and forth was racy. This new diff then concatenates
these structures like [ifqueue, hfsc_if, altq-bits], has some better
names, doesn't need renaming stuff in the old code (it can remain 2
years old), removes the now useless ifq_hfsc pointer.
As always, it's being heavily tested.
--
Martin Pelikan
? net/hfsc.c.instrumented
Index: altq/if_altq.h
===
RCS file: /cvs/src/sys/altq/if_altq.h,v
retrieving revision 1.16
diff -u -p -r1.16 if_altq.h
--- altq/if_altq.h 12 Oct 2013 12:13:10 - 1.16
+++ altq/if_altq.h 20 Oct 2013 21:25:41 -
@@ -36,6 +36,13 @@ struct altq_pktattr; struct oldtb_regula
/*
* Structure defining a queue for a network interface.
*/
+
+/* XXX hack, because we need the structure definition */
+#define ALTQ_IS_ENABLED1
+#include net/hfsc.h
+#undef ALTQ_IS_ENABLED
+/* XXX hack */
+
struct ifaltq {
/* fields compatible with struct ifqueue */
struct {
@@ -45,8 +52,8 @@ structifaltq {
int ifq_len;
int ifq_maxlen;
int ifq_drops;
- struct hfsc_if *ifq_hfsc;
struct timeout *ifq_congestion;
+ struct hfsc_if ifq_hfsc;
/* alternate queueing related fields */
int altq_type; /* discipline type */
Index: net/hfsc.c
===
RCS file: /cvs/src/sys/net/hfsc.c,v
retrieving revision 1.1
diff -u -p -r1.1 hfsc.c
--- net/hfsc.c 12 Oct 2013 11:39:17 - 1.1
+++ net/hfsc.c 20 Oct 2013 21:25:42 -
@@ -63,7 +63,7 @@
/*
* function prototypes
*/
-struct hfsc_class *hfsc_class_create(struct hfsc_if *,
+struct hfsc_class *hfsc_class_create(struct ifqueue *,
struct hfsc_sc *, struct hfsc_sc *,
struct hfsc_sc *, struct hfsc_class *, int,
int, int);
@@ -128,18 +128,49 @@ hfsc_microuptime(void)
HFSC_CLK_SHIFT);
}
+/*
+ * The new table will be exactly one page larger, so in the most
+ * common case of 8B pointers and 4KB pages it's 512 more classes.
+ * Returns the amount of classes, so all new pages are 100% utilized.
+ */
+static inline u_int
+hfsc_more_slots(u_int current)
+{
+ u_int was_pages = current * sizeof(void *) / PAGE_SIZE;
+ u_int n = ((was_pages + 1) * PAGE_SIZE) / sizeof(void *);
+
+ return (n);
+}
+
+static void
+hfsc_grow_class_tbl(struct hfsc_if *hif)
+{
+ struct hfsc_class **newtbl, **old = hif-hif_class_tbl;
+ const u_int slots = hfsc_more_slots(hif-hif_allocated);
+
+ newtbl = malloc(slots * sizeof(void *), M_DEVBUF, M_WAITOK | M_ZERO);
+ memcpy(newtbl, old, hif-hif_allocated * sizeof(void *));
+
+ hif-hif_allocated = slots;
+ hif-hif_class_tbl = newtbl;
+
+ free(old, M_DEVBUF);
+}
+
int
hfsc_attach(struct ifnet *ifp)
{
- struct hfsc_if *hif;
+ const u_int slots = hfsc_more_slots(0);
+ const size_t sz = slots * sizeof(void *);
+ struct hfsc_if *hif = ifp-if_snd.ifq_hfsc;
- if (ifp-if_snd.ifq_hfsc != NULL)
+ if (hif-hif_class_tbl != NULL)
return (0);
- hif = malloc(sizeof(struct hfsc_if), M_DEVBUF, M_WAITOK|M_ZERO);
+ hif-hif_class_tbl = malloc(sz, M_DEVBUF, M_WAITOK | M_ZERO);
+ hif-hif_allocated = slots;
+ hif-hif_classes = 0;
hif-hif_eligible = hfsc_ellist_alloc();
- hif-hif_ifq = (struct ifqueue *)ifp-if_snd; /* XXX cast temp */
- ifp-if_snd.ifq_hfsc = hif;
return (0);
}
@@ -147,8 +178,11 @@ hfsc_attach(struct ifnet *ifp)
int
hfsc_detach(struct ifnet *ifp)
{
- free(ifp-if_snd.ifq_hfsc, M_DEVBUF);
- ifp-if_snd.ifq_hfsc = NULL;
+ struct hfsc_if *hif = ifp-if_snd.ifq_hfsc;
+
+ hif-hif_allocated = hif-hif_classes = 0;
+ free(hif-hif_class_tbl, M_DEVBUF);
+ hif-hif_class_tbl = NULL;
return (0);
}
@@ -156,11 +190,13 @@ hfsc_detach(struct ifnet *ifp)
int
hfsc_addqueue(struct pf_queuespec *q)
{
- struct hfsc_if *hif;
+ /* XXX remove the cast when ifaltq is gone. */
+ struct ifqueue *ifq = (struct ifqueue *)q-kif-pfik_ifp-if_snd;
+ struct hfsc_if *hif = ifq-ifq_hfsc;
struct hfsc_class *cl, *parent;
struct hfsc_sc rtsc, lssc, ulsc;
- if ((hif = q-kif-pfik_ifp-if_snd.ifq_hfsc) == NULL)
+ if (hif-hif_allocated == 0)
return (EINVAL);
if (q-parent_qid == HFSC_NULLCLASS_HANDLE
@@ -185,7 +221,7 @@ hfsc_addqueue(struct pf_queuespec *q)
ulsc.d = q-upperlimit.d;
ulsc.m2 = q-upperlimit.m2.absolute;
- cl = hfsc_class_create(hif, rtsc, lssc, ulsc,
+ cl = hfsc_class_create(ifq, rtsc, lssc, ulsc,
parent, q-qlimit, q-flags, q-qid);
if (cl == NULL)
Re: partial xlocale(3) port from FreeBSD
Obviously, our locale support still sucks, this patch is mostly providing the API for filling the blanks later. Which blanks exactly? Locale features we don't have, such as collation? Yes. The features why for example PostgreSQL won't sort tables correctly, which if you live in a country with weird characters in their language is... quite unfortunate. I was planning on bringing specifically LC_COLLATE support for a long time, but it's quite a lot of work. (and testing, and bugfixing with languages I don't even know existed) How much did the ramdisks grow by when you built release with this? Having just freed up a bunch of space on the ramdisks, I'll be pissed if we squander it all immediately. No objections against #ifndef SMALL_KERNEL-ing the big bits. I'm not very excited about xlocale. If the only goal here is an API shim to compile a C++ library, can't we put the shim somewhere else than libc? Like the misc/libutf8 port we used to have? Thought about it too, but since apps expect to find this stuff in libc, I went for a libc diff hoping that porters will have their lives easier. The functions I ported were the ones ld-2.17 complained about. I have no idea whether that port is complete and I don't claim the diff to be ready. It gets the job done at the cost of being huge and probably wrong in places, and is open for discussion. I don't care about xlocale either. What'd I like is to have C++11 working out of the box for the next release (Is that real?) and hopefully collation support some time in the future. Later in the process I noticed there is an even smaller shim intended for Solaris as a part of libcxx, but my thoughts were: - Locale has always been a pain in the ass, but something users demand. (or is it just me with postgresql?) - Sharing this stuff with FreeBSD will make our lives easier should anything go wrong with it. Less work for us + satisfied customers. - We don't have to be complete, or even advertise it very much. But stuff that is increasingly popular (like C++11) will work out of the box. The ability to use modern toolchains for ports should make the latency-savvy desktop users happier. - Since a lot of operating systems have now adopted solutions (being it xlocale or others), I suspect libcxx maintainers won't be very happy about #ifdef __OpenBSD__ remove half of the functionality Please correct me if the philosophy is wrong. Or better, suggest other ways forward :-) -- Martin Pelikan
