On Tue, Jul 05, 2016 at 01:39:18AM -0400, Ian Sutton wrote:
> On Mon, Jul 4, 2016 at 10:30 PM, Jonathan Gray wrote:
> > Lack of fdt use aside, we don't want to enable something that
> > allows userspace access to system memory like this.
>
> I can understand this sentiment. Maybe next time..
>
>
On Mon, Jul 4, 2016 at 10:30 PM, Jonathan Gray wrote:
> Lack of fdt use aside, we don't want to enable something that
> allows userspace access to system memory like this.
I can understand this sentiment. Maybe next time..
Are you saying you are catagorically opposed to a PRU driver or just
oppo
"Todd C. Miller" writes:
> On Mon, 04 Jul 2016 14:45:57 +0200, Jeremie Courreges-Anglas wrote:
>
>> The two sockets we check for are SOCK_DGRAM sockets, I assumed that we
>> can't get POLLHUP on such sockets. Wrong assumption?
>
> That should be fine then, you can only get POLLHUP for connection
Mark Kettenis writes:
>> From: j...@wxcvbn.org (Jeremie Courreges-Anglas)
>> Date: Mon, 27 Jun 2016 23:40:35 +0200
>>
>> Mark Kettenis writes:
>>
>> > As reported by several people, mesa contains code that violates W^X.
>> > As a result glxgears aborts when using the swrast driver. The diff
>
On Wed, 29 Jun 2016, Todd C. Miller wrote:
> On Wed, 29 Jun 2016 07:05:15 -0600, "Todd C. Miller" wrote:
> > Don't you need to make a copy of dp->d_name? Returning dp->d_name
> > after closedir() seems dangerous.
>
> Since closedir() frees dd_buf this would result in a user after free.
Yep. Too
On Wed, 29 Jun 2016, Marc Espie wrote:
> On Tue, Jun 28, 2016 at 09:46:30PM -0700, Philip Guenther wrote:
> > Inspired by espie@'s ttyname.c diff, here's a simplification of libc's
> > fallback-to-scanning-/dev code for devname(). Since devname() returns
> > the "name under /dev", this eliminate
On Mon, Jul 04, 2016 at 05:37:05AM -0400, Ian Sutton wrote:
> I have written some software to support the PRU (Programmable Realtime
> Unit) integrated in Texas Instrument's line of ARM SoCs, specifically
> the am335x chips. The PRU is a 32-bit realtime processor that exists as
> a subsystem on the
ok beck@, with an appropriate commit message
On Mon, Jul 04, 2016 at 06:59:28PM -0500, Brent Cook wrote:
> I copied some of the commit text here from BoringSSL, but it's wrong for
> LibreSSL it seems.
>
> BN_ULLONG is not defined on all 64-bit systems as far as I can tell. So, this
> fix is mo
Incorrect.
It is up to the in-kernel ioctl code for each fd (decides subsystem)
and command to decide what it means. Quite a few of them do take int.
Anways, I'll quote POSIX:
The arg argument represents additional information that is needed by
this specific STREAMS device to perform th
The diff below adds a little improvement to the wsmouse_matching
function, which is the core of the MT tracking mechanism in wsmouse.
Sadly, that mechanism isn't in use up to now, but this also means
that OKs are riskless ;-)
With small matrices - roughly, of orders up to 300 or 400 - and most
ki
ioctl param is always a pointer, previous wording implied int literal
could be passed (results in EFAULT)
Index: ioctl.2
===
RCS file: /cvs/src/lib/libc/sys/ioctl.2,v
retrieving revision 1.18
diff -u -p -r1.18 ioctl.2
--- ioctl.2
I copied some of the commit text here from BoringSSL, but it's wrong for
LibreSSL it seems.
BN_ULLONG is not defined on all 64-bit systems as far as I can tell. So, this
fix is more widely applicable than Win64 for LibreSSL.
Any comments?
- Brent
> On Jun 30, 2016, at 8:40 AM, Brent Cook wr
> From: j...@wxcvbn.org (Jeremie Courreges-Anglas)
> Date: Mon, 27 Jun 2016 23:40:35 +0200
>
> Mark Kettenis writes:
>
> > As reported by several people, mesa contains code that violates W^X.
> > As a result glxgears aborts when using the swrast driver. The diff
> > below disables the offending
On July 4, 2016 11:06:28 PM GMT+02:00, Alexander Hall
wrote:
>
>
>On July 4, 2016 5:51:06 PM GMT+02:00, Bob Beck
>wrote:
>>>
>>> Thinking of it again, you could possibly just use the action
>>arguments for
>>> a more generic "execute-program" action.
>>>
>>
>>Ahhh.. are you insane? The way yo
On July 4, 2016 5:51:06 PM GMT+02:00, Bob Beck wrote:
>>
>> Thinking of it again, you could possibly just use the action
>arguments for
>> a more generic "execute-program" action.
>>
>
>Ahhh.. are you insane? The way you get a generic "execute program"
>action is to LOG IN TO THE DAMN MACHINE!
> On 2016-07-04 22:17, Theo de Raadt wrote:
> > Absolutely no way for your change.
> >
> > It is correct.
> >
> >> I'm just wondering if true.c does really need int argc and char
> >> *argv[]
> >> rather than void (src/usr.bin/true/true.c), if not:
> >>
> >> Index: true.c
> >> =
Absolutely no way for your change.
It is correct.
> I'm just wondering if true.c does really need int argc and char *argv[]
> rather than void (src/usr.bin/true/true.c), if not:
>
> Index: true.c
> ===
> RCS file: /cvs/src/usr.bin/
I'm just wondering if true.c does really need int argc and char *argv[]
rather than void (src/usr.bin/true/true.c), if not:
Index: true.c
===
RCS file: /cvs/src/usr.bin/true/true.c,v
retrieving revision 1.1
diff -r1.1 true.c
6c6
< m
On Mon, 04 Jul 2016 14:45:57 +0200, Jeremie Courreges-Anglas wrote:
> The two sockets we check for are SOCK_DGRAM sockets, I assumed that we
> can't get POLLHUP on such sockets. Wrong assumption?
That should be fine then, you can only get POLLHUP for connection-oriented
sockets.
- todd
I mean, in all seriousness, what you want to do is probably more
safely accomplished by having a way for the "owner"
of the machine to configure it to just log them in without a password,
and then pop a program like xlock that locks their
screen and presents the hibernate suspend and other such bul
>
> Thinking of it again, you could possibly just use the action arguments for
> a more generic "execute-program" action.
>
Ahhh.. are you insane? The way you get a generic "execute program"
action is to LOG IN TO THE DAMN MACHINE!
Why don't you guys just make an option so someone can set up thei
> On Mon, Jul 4, 2016 at 6:42 AM, Craig Skinner wrote:
> > On 2016-07-02 Sat 11:21 AM |, Bob Beck wrote:
> >> On Saturday, 2 July 2016, Craig Skinner wrote:
> >> >
> >> > xmessage is now run as '_x11', shutdown as 'operator', and the status
> >> > items as 'nobody'. Only user _x11's xmessage wind
On Mon, Jul 4, 2016 at 6:42 AM, Craig Skinner wrote:
> On 2016-07-02 Sat 11:21 AM |, Bob Beck wrote:
>> On Saturday, 2 July 2016, Craig Skinner wrote:
>> >
>> > xmessage is now run as '_x11', shutdown as 'operator', and the status
>> > items as 'nobody'. Only user _x11's xmessage windows are pkil
On Mon, Jul 04, 2016 at 01:03:22PM +0200, Martin Pieuchot wrote:
> + if (ip6_hbhchcheck(m, &off, &nxt, &ours)) {
> + if_put(ifp);
> + return; /* m have already been freed */
> }
As ip6_hbhchcheck() does ip6 = mtod(m, struct ip6_hdr *) after
ip6_hopopts_input() you
On Mon, Jul 04, 2016 at 01:12:24PM +0200, Martin Pieuchot wrote:
> I find IPv6 address states (flags) really hard to follow. This macro
> doesn't seem to help as it is not always used. I'd like to get rid of
> it, any concern?
OK bluhm@
>
> After applying this diff you'll see that some pattern
"Todd C. Miller" writes:
> On Mon, 04 Jul 2016 12:43:12 +0200, Jeremie Courreges-Anglas wrote:
>
>> Showing this to a wider audience,
>>
>> This was initially prompted by a diff to replace calloc with
>> reallocarray. As noted by guenther, there is a problem with the
>> comparisons between widt
On 2016-07-02 Sat 11:21 AM |, Bob Beck wrote:
> On Saturday, 2 July 2016, Craig Skinner wrote:
> >
> > xmessage is now run as '_x11', shutdown as 'operator', and the status
> > items as 'nobody'. Only user _x11's xmessage windows are pkilled.
> >
>
> Do not use nobody.
>
> that is a very bad pra
On Mon, 04 Jul 2016 12:43:12 +0200, Jeremie Courreges-Anglas wrote:
> Showing this to a wider audience,
>
> This was initially prompted by a diff to replace calloc with
> reallocarray. As noted by guenther, there is a problem with the
> comparisons between width, rpcsock and pingsock; this, plus
I find IPv6 address states (flags) really hard to follow. This macro
doesn't seem to help as it is not always used. I'd like to get rid of
it, any concern?
After applying this diff you'll see that some patterns appear and they
make me wonder, are some IN6_IFF_DETACHED missing?
Index: netinet6/i
One of my trees now contain all the necessary plumbing to run the IPv6
forwarding path (mostly) without holding the KERNEL_LOCK. In other
words we should be able to unlock IPv6 and legacy IP at the same time.
However it's a bit tricky to enqueue packets for local delivery in IPv6
because of the H
Showing this to a wider audience,
This was initially prompted by a diff to replace calloc with
reallocarray. As noted by guenther, there is a problem with the
comparisons between width, rpcsock and pingsock; this, plus the fd_set
allocation inconvenience would be easily fixed by moving from sele
I have written some software to support the PRU (Programmable Realtime
Unit) integrated in Texas Instrument's line of ARM SoCs, specifically
the am335x chips. The PRU is a 32-bit realtime processor that exists as
a subsystem on the SoC. You can read more about it in the linked man
pages.
Included
On 03/07/16(Sun) 15:23, Stefan Sperling wrote:
> For hostap interfaces, ifconfig scan currently shows the maximum supported
> Rx Rate or RX MCS of associated stations. E.g. for an iwn(4) device associated
> to an athn(4) AP in 11g mode, the AP will show 'HT-MCS7' in ifconfig scan:
>
> # ifconfig
33 matches
Mail list logo
