...and here's a diff for discussion that removes the sa_family_t and
socklen_t typedefs from sys/types.h, transferring them to sys/socket.h and
duping them in netinet/in.h, netinet6/in6.h, and sys/un.h as necessary.
There are only two user-land fixes necessary for a build with this, in
sasyncd
X PP5P6P4QP=P0QPP4P=P0Q P=P0QQP=P-P?QP0P:QP8QP5QP:P0Q
P:PP=QP5QP5P=QP8Q
bPQQP;P5P4PP2P0P=P8P5, QP0P7QP0P1PQP:P0 P8 P?QP8PP5P=P5P=P8P5
PQQPP:P8Q PP5QP=PP;PP3P8P8 P2 P?QPPQQP;P5P=P=PQQP8b
9-11 P4P5P:P0P1QQ 2010, P3. P!P0P=P:Q-PP5QP5QP1QQP3, P PQQP8Q
www.htfr.org,
On Thu, Oct 21, 2010 at 7:36 PM, Laurence Tratt lau...@tratt.net wrote:
18 months ago I posted a patch to make apmd's -C and -A modes work
half-sensibly on multi-processor machines:
http://marc.info/?l=openbsd-techm=123315164930014w=2
The patch went into the tree but was backed out because
Is this enough to compile socket.h by itself? I think sockcred needs
to be hidden inside bsd visible too, because you aren't providing
uid_t that i can see.
On Sun, Nov 21, 2010 at 3:45 AM, Philip Guenther guent...@gmail.com wrote:
...and here's a diff for discussion that removes the
On Sat, Nov 20, 2010 at 4:36 AM, Kenneth R Westerback
kwesterb...@rogers.com wrote:
Is it as simple as a missing m_pullup(), which is apparently what
ieee8011_encap() does in the situation?
Looks very logical. I just applied this and booted the new kernel. Of
course it always took days before
On Sat, 20 Nov 2010, Ted Unangst wrote:
this diff adds a -N flag to turn off this behavior, -N for numeric (or no
names, if you prefer). i found a similar --long-option-only in gnu tar.
slightly improved. should now work for creating archives as well, and
some man page improvemnts.
Index:
Now SunMouse works through wsmouse(sunms add miod@ 20 May 2009)
so we can remove our patch to SunMouse for xf86-input-mouse.
Right? OK?
--
Alexandr Shadchin
Index: driver/xf86-input-mouse/src/mouse.c
===
RCS file:
instead of faking an assertwaitok check, let's use the real thing. this
is almost the opposite of progress on the whole bluetooth issue, but it
shortens the stack trace considerably. the curproc check isn't terribly
accurate, either, so it misses bugs.
i don't see any reason to avoid
is any of this useful? has anybody ever manually stirred the random
device or tried interpreting the nonsense spit out by sysctl
kern.random?
[this would also delete the rndioctl.h header entirely.]
Index: dev/rnd.c
===
RCS file:
On 11/22/10 01:16, Ted Unangst wrote:
is any of this useful? has anybody ever manually stirred the random
device or tried interpreting the nonsense spit out by sysctl
We stir it in the installer, FWIW.
On 11/22/10 01:35, Alexander Hall wrote:
On 11/22/10 01:16, Ted Unangst wrote:
is any of this useful? has anybody ever manually stirred the random
device or tried interpreting the nonsense spit out by sysctl
We stir it in the installer, FWIW.
Hmmm... For my definition of stirr, which I
It had to happen. A USB CD device has been found that 'forgets' to mention
that it is a removable device. PR #6513.
Therefore tweak the cd recognition pattern to accept T_FIXED cdrom and
worm devices.
Can anybody think of any reason to not do this? Submitter should be
testing this as I write to
On Sun, Nov 21, 2010 at 7:29 PM, Alexander Hall ha...@openbsd.org wrote:
On 11/21/10 18:15, Ted Unangst wrote:
On Sat, 20 Nov 2010, Ted Unangst wrote:
this diff adds a -N flag to turn off this behavior, -N for numeric (or no
names, if you prefer). i found a similar --long-option-only in gnu
On Sun, Nov 21, 2010 at 09:44:12AM -0800, Greg Steuck wrote:
On Sat, Nov 20, 2010 at 4:36 AM, Kenneth R Westerback
kwesterb...@rogers.com wrote:
Is it as simple as a missing m_pullup(), which is apparently what
ieee8011_encap() does in the situation?
Looks very logical. I just applied
On 11/22/10 01:16, Ted Unangst wrote:
is any of this useful? has anybody ever manually stirred the random
device or tried interpreting the nonsense spit out by sysctl
We stir it in the installer, FWIW.
Using the xxxwrite() entry point.
On Sun, Nov 21, 2010 at 06:47:01PM -0500, Ted Unangst wrote:
instead of faking an assertwaitok check, let's use the real thing. this
is almost the opposite of progress on the whole bluetooth issue, but it
shortens the stack trace considerably. the curproc check isn't terribly
accurate,
This diff from FreeBSD adds Marvell PHYG65G Gigabit PHY which is
found on 88E8059 Yukon Optima. Tested by Frans Haarman.
# dmesg | grep msk
mskc0 at pci3 dev 0 function 0 Marvell Yukon 88E8059 rev 0x11, Yukon-2
Optima (0x1): apic 1 int 19 (irq 11)
msk0 at mskc0 port A: address 1c:c1:de:9c:04:e2
17 matches
Mail list logo