Re: monop(6): drop the conditional shrt macro definitions

On Sat, Jun 10, 2017 at 2:45 PM, Miod Vallat wrote: >> Hi tech@, >> >> Drop the conditional shrt macro definitions and use short everywhere. > > Why not use uint8_t then? Isn't the point of the code to *not* use an unsigned type? Philip Guenther

Re: monop(6): drop the conditional shrt macro definitions

> Hi tech@, > > Drop the conditional shrt macro definitions and use short everywhere. Why not use uint8_t then?

monop(6): drop the conditional shrt macro definitions

Hi tech@, Drop the conditional shrt macro definitions and use short everywhere. Comments? OK? Index: games/monop/houses.c === RCS file: /cvs/src/games/monop/houses.c,v retrieving revision 1.10 diff -u -p -r1.10 houses.c ---

Re: htpasswd: use crypt_newhash instead of bcrypt API

Michal Mazurek wrote: > When talking about this with mulander@ it came out that the docs could > use a touch. > > The commit message for the diff that didn't update the docs was: > > permit "bcrypt" as an alias for "blowfish". this is, after all, what > 99% of the world calls it. >

Re: sppp(4)/pppoe(4) dynamic address hack

On 10/06/17(Sat) 17:45, Stefan Sperling wrote: > On Sat, Jun 10, 2017 at 04:14:16PM +0200, Martin Pieuchot wrote: > > I'm not fan of your approach because it makes pppoe(4) special, does > > umb(4) will need 'dynaddr' and 'dyntest' too? > > I consider this a quirk in sppp(4), not pppoe or p2p

Re: [PATCH] re: disable PCIe ASPM and ECPM (CLKREQ)

On Sat, Jun 10, 2017 at 11:06:43PM +0800, Kevin Lo wrote: > On Wed, May 17, 2017 at 03:58:16PM +0800, Kevin Lo wrote: > > > > >From FreeBSD (r227593, r307982): > > More and more RealTek controllers started to implement EEE feature. > > Vendor driver seems to load a kind of firmware for EEE with >

Re: sppp(4)/pppoe(4) dynamic address hack

On Sat, Jun 10, 2017 at 04:14:16PM +0200, Martin Pieuchot wrote: > If there's a real need for such arguments, because somebody use pppoe(4) > with static IP/route then why not. But that's not what you said. What > you said is that the current hack of 0.0.0.0+0.0.0.1 is broken. Static IP/route

Re: [PATCH] re: disable PCIe ASPM and ECPM (CLKREQ)

On Wed, May 17, 2017 at 03:58:16PM +0800, Kevin Lo wrote: > > >From FreeBSD (r227593, r307982): > More and more RealTek controllers started to implement EEE feature. > Vendor driver seems to load a kind of firmware for EEE with > additional PHY fixups. It is known that the EEE feature may need >

Re: sppp(4)/pppoe(4) dynamic address hack

On 10/06/17(Sat) 11:55, Stefan Sperling wrote: > On Sat, Jun 10, 2017 at 11:47:27AM +0200, Martin Pieuchot wrote: > > On 10/06/17(Sat) 08:35, Stefan Sperling wrote: > > > On Fri, Jun 09, 2017 at 05:37:44PM +0100, Jason McIntyre wrote: > > > > why do you have to specify 0.0.0.0 *and* dynaddr? > > >

Re: sed(1): missing NUL in pattern space

On Fri, Jun 09, 2017 at 07:58:48AM +, kshe wrote: > Hi, > > There is an ongoing confusion in sed's source about the concept of EOL: > the code contradicts itself as to whether it should be determined by a > trailing NUL or by looking up the `len' field of the SPACE structure. > > At least

Re: sppp(4)/pppoe(4) dynamic address hack

On Sat, Jun 10, 2017 at 11:47:27AM +0200, Martin Pieuchot wrote: > On 10/06/17(Sat) 08:35, Stefan Sperling wrote: > > On Fri, Jun 09, 2017 at 05:37:44PM +0100, Jason McIntyre wrote: > > > why do you have to specify 0.0.0.0 *and* dynaddr? > > [...] > > Regardless, you probably *do* want a dummy

Re: htpasswd: use crypt_newhash instead of bcrypt API

On 21:16:08, 6.06.17, Michal Mazurek wrote: > When talking about this with mulander@ it came out that the docs could > use a touch. > > The commit message for the diff that didn't update the docs was: > > permit "bcrypt" as an alias for "blowfish". this is, after all, what > 99% of the

Re: sppp(4)/pppoe(4) dynamic address hack

On Sat, Jun 10, 2017 at 10:22:22AM +0200, Stefan Sperling wrote: > On Sat, Jun 10, 2017 at 08:35:13AM +0100, Jason McIntyre wrote: > > thanks. the ifconfig.8 bits look good, but i think you should also > > change the examples given in pppoe(4) to show the updated syntax, to > > prepare folks. > >

Re: sppp(4)/pppoe(4) dynamic address hack

On Sat, Jun 10, 2017 at 08:35:13AM +0100, Jason McIntyre wrote: > thanks. the ifconfig.8 bits look good, but i think you should also > change the examples given in pppoe(4) to show the updated syntax, to > prepare folks. > > actually i think it would be better to discuss the deprecated stuff > in

Re: sppp(4)/pppoe(4) dynamic address hack

On Sat, Jun 10, 2017 at 09:23:45AM +0200, Stefan Sperling wrote: > On Fri, Jun 09, 2017 at 06:33:46PM +0200, Stefan Sperling wrote: > > This diff changes the way dynamic addresses are configured in sppp(4). > > I was asked in private whether we could avoid a flag day which makes > it inconvenient

Re: sppp(4)/pppoe(4) dynamic address hack

On Fri, Jun 09, 2017 at 06:33:46PM +0200, Stefan Sperling wrote: > This diff changes the way dynamic addresses are configured in sppp(4). I was asked in private whether we could avoid a flag day which makes it inconvenient to upgrade remote boxes only reachable over pppoe(4). I see no harm in

Re: sppp(4)/pppoe(4) dynamic address hack

On Fri, Jun 09, 2017 at 10:36:45PM +0200, Christian Weisgerber wrote: > The example in the pppoe(4) man page also includes > > !/sbin/route add default -ifp pppoe0 0.0.0.1 > > to specify the default route. What happens to that? Good question. It raises an interesting point: Setting a

Re: sppp(4)/pppoe(4) dynamic address hack

On Fri, Jun 09, 2017 at 05:37:44PM +0100, Jason McIntyre wrote: > why do you have to specify 0.0.0.0 *and* dynaddr? If there is no address on the interface, the code in sppp_set_ip_addrs() loops over an empty interface address list and hence does nothing. IPCP will still negotiate an address but