On Tue, Apr 12, 2016 at 06:24:10AM +, Miod Vallat wrote:
> > wskbd_enable (calls pckbd_enable) does not appear to be called from
> > wskbd_activate, perhaps just calling wskbd_enable from there would be
> > better? (as a matter of fact, wskbd_activate doesn't really do much at
> > all except se
As reported by jsg@ the wifi stack should use if_start() just like the
rest of the kernel. One of the patterns can even be converted to
if_enqueue().
Tested with:
iwn0 at pci2 dev 0 function 0 "Intel Centrino Advanced-N 6205" rev 0x34
ok?
Index: net80211/ieee80211_input.c
> wskbd_enable (calls pckbd_enable) does not appear to be called from
> wskbd_activate, perhaps just calling wskbd_enable from there would be
> better? (as a matter of fact, wskbd_activate doesn't really do much at
> all except set sc_dying=1, and I'm not sure where that gets reset.)
Nooo! wsk
Sun, 10 Apr 2016 14:23:02 -0700 Brennan Vincent
> Got it. Thanks for the explanation.
>
> On Sun, Apr 10, 2016, at 01:36 PM, Stuart Henderson wrote:
> > On 2016/04/10 20:50, Nicholas Marriott wrote:
> > > Hi
> > >
> > > What's the use for this? What program could use it?
> > >
> > > On Sun, A
Mon, 11 Apr 2016 15:59:53 +0200 Mike Belopuhov
> On 11 April 2016 at 15:51, Mark Kettenis wrote:
> >
> > And prototypes with names in public headers are still an issue.
> >
>
> Interesting point. What's a public header though?
> Are files that end up in /usr/include/dev/pci/ public headers?
>
Hi Philip,
Philip Guenther wrote on Sun, Apr 10, 2016 at 08:16:21PM -0700:
> On Sun, Apr 10, 2016 at 9:16 AM, Ingo Schwarze wrote:
>> By the way, since sendsyslog(2) is only intended to be called by
>> syslog(3) and not directly by application code, i'd prefer to have
>> syslog(3) listed instead
Hi Sebastien,
Sebastien Marie wrote on Mon, Apr 11, 2016 at 11:18:34AM +0200:
> Comments ?
OK schwarze@.
You may want to consider the nits below, but my OK doesn't depend
on them.
By the way, the sysctl(3) manual seems to be lacking information
about NET_RT_TABLE, if somebody wants to look int
On Mon, Apr 11, 2016 at 11:23:57PM +0200, Martin Pieuchot wrote:
> On 10/04/16(Sun) 23:33, Mike Larkin wrote:
> > Please test this diff on all machines that you can successfully (today)
> > resume with 'zzz'. Please make sure that after resume, the keyboard
> > still works.
> >
> > This diff re-en
On 10/04/16(Sun) 23:33, Mike Larkin wrote:
> Please test this diff on all machines that you can successfully (today)
> resume with 'zzz'. Please make sure that after resume, the keyboard
> still works.
>
> This diff re-enables the keyboard on resume. Previously, we were re-enabling
> the keyboard
Hi! I am hitting an issue in efiboot on my HP Stream 13. Patch below. Sorry
if this is the wrong list.
When trying to boot current with the EFI bootloader it hangs:
probing: pc0 mem[444K 88K 511M 1374M 19M]
disk: hd0 hd1* hd2* hd3* hd4_ <- hangs.
Then it stops responding and I have to power
On Mon, Apr 11, 2016 at 11:49 AM, Miod Vallat wrote:
> The point is that putting argument names in
> public headers increases the risk of breaking third-party software
> thanks to the preprocessor.
The safe way for the implementation (us!) to do that is to use
identifiers that start with an under
Miod Vallat wrote:
>
> >> fwiw i like names in prototypes, so i know what's going on. i know
> >> style says that, but i think the advice is obsolete.
> >
> > The compiler doesn't check that the argument names in the prototype
> > match those in the definition. The below program compiles without
>
>> fwiw i like names in prototypes, so i know what's going on. i know
>> style says that, but i think the advice is obsolete.
>
> The compiler doesn't check that the argument names in the prototype
> match those in the definition. The below program compiles without
> warning.
This is not the poin
Running pstat with either [-M core] or [-N system] along with the -T option
results in a segmentation fault. Make sure kvm access is initialized prior
to running kvm_read() when -T is specified.
This issue appears to have been introduced when setgid kmem support was
removed in revision 1.99.
Rob
On 04/10/16 23:33, Mike Larkin wrote:
Please test this diff on all machines that you can successfully (today)
resume with 'zzz'. Please make sure that after resume, the keyboard
still works.
This diff re-enables the keyboard on resume. Previously, we were re-enabling
the keyboard *controller* bu
On Mon, Apr 11, 2016 at 04:02:34PM +0200, Mark Kettenis wrote:
> > Date: Sun, 10 Apr 2016 23:33:59 -0700
> > From: Mike Larkin
> >
> > Please test this diff on all machines that you can successfully (today)
> > resume with 'zzz'. Please make sure that after resume, the keyboard
> > still works.
>
Ted Unangst wrote:
> Martin Pieuchot wrote:
> > ok?
> >
> > -int chillbufs(struct
> > -bufcache *cache, struct bufqueue *queue, int64_t *queuepages);
> > +int chillbufs(struct bufcache *, struct bufqueue *, int64_t *);
>
> fwiw i like names in prototypes, so i know what's going on. i know
> s
guys. i have stuff outstanding in here. find something else to bikeshed
please
On Monday, 11 April 2016, Ted Unangst wrote:
> Mark Kettenis wrote:
> > And prototypes with names in public headers are still an issue.
>
> I think you misspelled standard. :)
>
>
Mark Kettenis wrote:
> And prototypes with names in public headers are still an issue.
I think you misspelled standard. :)
> On 8 Apr 2016, at 12:58 AM, Martin Pieuchot wrote:
>
> I'd like to add a lock/unlock the remaining parts of the IPv4 forwarding
> path that still require some work:
>
> 1/ IP source options
> 2/ per-ifp lookups related to multicast traffic
> 3/ IPsec lookups
>
> This should not matter for th
On 11 April 2016 at 15:51, Mark Kettenis wrote:
>
> And prototypes with names in public headers are still an issue.
>
Interesting point. What's a public header though?
Are files that end up in /usr/include/dev/pci/ public headers?
If so, why do we install all of them indiscriminately?
> Date: Sun, 10 Apr 2016 23:33:59 -0700
> From: Mike Larkin
>
> Please test this diff on all machines that you can successfully (today)
> resume with 'zzz'. Please make sure that after resume, the keyboard
> still works.
>
> This diff re-enables the keyboard on resume. Previously, we were re-ena
> From: "Ted Unangst"
> Date: Mon, 11 Apr 2016 09:44:26 -0400
>
> Martin Pieuchot wrote:
> > ok?
> >
> > -int chillbufs(struct
> > -bufcache *cache, struct bufqueue *queue, int64_t *queuepages);
> > +int chillbufs(struct bufcache *, struct bufqueue *, int64_t *);
>
> fwiw i like names in pr
Martin Pieuchot wrote:
> ok?
>
> -int chillbufs(struct
> -bufcache *cache, struct bufqueue *queue, int64_t *queuepages);
> +int chillbufs(struct bufcache *, struct bufqueue *, int64_t *);
fwiw i like names in prototypes, so i know what's going on. i know style says
that, but i think the advic
Instead of rtfree(9)ing the cached route after using it, if it is a
multipath one, free it before.
Ok?
Index: netinet/ip_input.c
===
RCS file: /cvs/src/sys/netinet/ip_input.c,v
retrieving revision 1.269
diff -u -p -r1.269 ip_input.c
``ipforward_rt'' is going away but rather than sending a big diff,
here's the first step.
This diff replaces in_rtaddr() by rtalloc(9). Note that since the code
here is interested in rt_ifa it has to call rtisvalid(9) to prevent a
NULL-dereference in case of a stale ``ifa''.
For the same reason
Martin Pieuchot writes:
> This variable is also used for route lookups, so it must always be
> assigned.
>
> ok?
ok jca@
> Index: netinet6//ip6_input.c
> ===
> RCS file: /cvs/src/sys/netinet6/ip6_input.c,v
> retrieving revision 1.1
On 11 April 2016 at 13:16, Martin Pieuchot wrote:
> This variable is also used for route lookups, so it must always be
> assigned.
>
> ok?
>
OK. Initially there was some pf glue that got removed.
This variable is also used for route lookups, so it must always be
assigned.
ok?
Index: netinet6//ip6_input.c
===
RCS file: /cvs/src/sys/netinet6/ip6_input.c,v
retrieving revision 1.156
diff -u -p -r1.156 ip6_input.c
--- netinet6//ip
On Thu, Apr 07, 2016 at 04:01:52PM -0400, Rob Pierce wrote:
> I wasn't sure of where to put it in the list.
>
> How is this?
>
> Rob
>
Hi,
Sorry for the late reply. We have discuted a bit the proper way to
document "route" promise.
Your diff is a good starting point for "route" promise.
The
30 matches
Mail list logo