Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

On Thu, Nov 12, 2015 at 02:52:01PM +0800, Michael W. Bombardieri wrote: > > > ok for removing xfree from aucat? > > > > > > > yes, ok ratchov; if later this causes me merges i'll find another > > solution. Feel free to do the same in usr.bin/sndiod, as it's > > almost the same. > > > > Same

pledge telnet

I really want to delete telnet entirely, but there are still occasions when someone might want to use it on an intranet. Other telnet tools are probably worse shape. This adds two pledge calls. The subshell and skey support are removed (you can use ^Z), and you cannot start a new telnet

MALLOC_STATS and pledge

Hi all, I ve tried to discuss this point with Otto Moerbeek but he might be very busy so I throw the topic here if you do not mind ... I have the habit to enable MALLOC_STATS but with the recent pledge feature, it s now difficult to debug some pledged applications with MALLOC_OPTIONS=D as, for

Re: initial 802.11n implementation

On Thu, Nov 12, 2015 at 08:22:07PM +0100, Stefan Sperling wrote: > This diff adds an initial implementation of 802.11n. While testing this diff, please pay attention to stuttering behaviour in audio before and after applying this diff. If you're hearing audio stutter as a side effect of this

Re: initial 802.11n implementation

On 12/11/15(Thu) 20:22, Stefan Sperling wrote: > This diff adds an initial implementation of 802.11n. > > [...] Looks good. I think you should already put in the chunks below. Especially the one needed for ifconfig(8). I think I found a typo... > Index: net/if_media.h >

Re: Driver for Attansic Technology E2200.

Hi Martin, good afternoon. First of all, I want to thank your reply with the comments about the device driver. I answer you email next to you comments. 2015-11-09 11:30 GMT+01:00 Martin Pieuchot : > Hello Guillermo, > > On 08/11/15(Sun) 17:06, Guillermo Bernaldo de Quiros

Re: httpd URL rewrite support patch

Excuse me, the indentation was removed because message wasn't plain text. Patch: http://pastebin.com/XnZLEPEk httpd.conf: http://pastebin.com/gGp3NqCD rewr.php: http://pastebin.com/prA1NJXC

Re: telnet: Delete tracefile command.

Hi Theo, > CVSROOT: /cvs > Module name: src > Changes by: dera...@cvs.openbsd.org 2015/11/13 09:53:46 > > Modified files: > usr.bin/telnet : commands.c telnet.1 > > Log message: > Delete tracefile command. Tracefiles can now only be specified at > program startup. Who uses

Re: pledge telnet

> > I really want to delete telnet entirely, > > I often use it for testing unencrypted SMTP and HTTP across the > Internet. Which tool would you recommend for that purpose? nc(1). > You might wish to cross-check these three points though: > > * Does "inet" actually allow the following

Re: pledge telnet

Hi Theo, Theo de Raadt wrote on Fri, Nov 13, 2015 at 01:36:23AM -0700: > I really want to delete telnet entirely, I often use it for testing unencrypted SMTP and HTTP across the Internet. Which tool would you recommend for that purpose? > but there are still occasions when someone might want

Re: pledge telnet

On 2015/11/13 09:59, Theo de Raadt wrote: > > > I really want to delete telnet entirely, > > > > I often use it for testing unencrypted SMTP and HTTP across the > > Internet. Which tool would you recommend for that purpose? > > nc(1). I use telnet fairly often for connecting to things like

httpd URL rewrite support patch

Hello everyone, I'm new to OpenBSD and the tech@ list. I need to run a WordPress-like URL rewriting scheme for my blog. Basically URLs of the form /long-fancy-blog-post-title/ to be translated to /index.php?q=long-fancy-blog-post-title. I couldn't find this function in OpenBSD's new httpd which

Re: em(4) watchdog timeouts

On Wed, Nov 11, 2015 at 9:20 AM, Gregor Best wrote: > I've done some further testing and I think I've narrowed it down to the > "Unlocking em(4) a bit further"-patch [0]. That was the start of it for me. When I could revert to rev 1.305 for if_em.c and rev 1.57 for if_em.h

Re: pledge("stdio") for arch(1)/machine(1)

> This straightforward pledge("stdio") is one of the last uncommitted ones > from Theo's big 'tame in userland' diff and seems to have been > overlooked so far. I think arch.c gains no value from being pledged. It adds a system call to a program which makes no user-input decisions.

Re: pledge telnet

On Fri, 13 Nov 2015 17:52:21 +0100, Ingo Schwarze wrote: > I often use it for testing unencrypted SMTP and HTTP across the > Internet. Which tool would you recommend for that purpose? nc - todd

Re: pledge("stdio") for arch(1)/machine(1)

Hi, Theo de Raadt wrote on Fri, Nov 13, 2015 at 08:21:41AM -0700: > Theo Buehler wrote: >> This straightforward pledge("stdio") is one of the last uncommitted ones >> from Theo's big 'tame in userland' diff and seems to have been >> overlooked so far. > I think arch.c gains no value from being

pledge route(8) with '-n' flag

Hello, If '-n' argument is used on route(8) then nflag will be active and dns transactions won't be needed, am I correct? Index: route.c === RCS file: /cvs/src/sbin/route/route.c,v retrieving revision 1.179 diff -u -p -u -r1.179

Re: pledge telnet

> > > > I really want to delete telnet entirely, > > > > > > I often use it for testing unencrypted SMTP and HTTP across the > > > Internet. Which tool would you recommend for that purpose? > > > > nc(1). > > I use telnet fairly often for connecting to things like crappy switches, > crappy

Re: pledge telnet

On Fri, Nov 13, 2015 at 8:40 PM, Theo de Raadt wrote: >> > On 2015/11/13 09:59, Theo de Raadt wrote: >> > > > > I really want to delete telnet entirely, >> > > > >> > > > I often use it for testing unencrypted SMTP and HTTP across the >> > > > Internet. Which tool would

Re: pledge route(8) with '-n' flag

Ricardo Mestre(ser...@helheim.mooo.com) on 2015.11.13 18:00:11 +: > Hello, > > If '-n' argument is used on route(8) then nflag will be active and dns > transactions won't be needed, am I correct? please find out yourself. at least the pledge call in monitor will fail with -n and your diff,

Re: pledge telnet

On Fri, Nov 13, 2015 at 9:00 PM, Theo de Raadt wrote: >> It is similar to (optional) XMODEM/ZMODEM disciplines over serial, IMO. > > No, it is similar to over the INTERNET, because the INTERNET > is nothing at all like a serial line, the later generally being nicely >

Re: pledge telnet

Stuart Henderson wrote: > On 2015/11/13 09:59, Theo de Raadt wrote: > > > > I really want to delete telnet entirely, > > > > > > I often use it for testing unencrypted SMTP and HTTP across the > > > Internet. Which tool would you recommend for that purpose? > > > > nc(1). > I use telnet fairly

Re: pledge telnet

> > On 2015/11/13 09:59, Theo de Raadt wrote: > > > > > I really want to delete telnet entirely, > > > > > > > > I often use it for testing unencrypted SMTP and HTTP across the > > > > Internet. Which tool would you recommend for that purpose? > > > > > > nc(1). > > I use telnet fairly often for

Re: MALLOC_STATS and pledge

David CARLIER wrote: > Hi all, > > I ve tried to discuss this point with Otto Moerbeek but he might be > very busy so I throw the topic here if you do not mind ... > > I have the habit to enable MALLOC_STATS but with the recent pledge > feature, it s now difficult to debug some pledged

Re: pledge("stdio") for arch(1)/machine(1)

Ingo Schwarze wrote: > Hi, > > Theo de Raadt wrote on Fri, Nov 13, 2015 at 08:21:41AM -0700: > > Theo Buehler wrote: > > >> This straightforward pledge("stdio") is one of the last uncommitted ones > >> from Theo's big 'tame in userland' diff and seems to have been > >> overlooked so far. > > >

Re: pledge telnet

> It is similar to (optional) XMODEM/ZMODEM disciplines over serial, IMO. No, it is similar to over the INTERNET, because the INTERNET is nothing at all like a serial line, the later generally being nicely contained to a single room. > The goal is to delete classic telnet entirely and make it

Re: pledge telnet

> Can telnet be extended to coexist with nc -F? Manual only mentions ssh. Please don't email while driving your horse buggy.

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Alexandre Ratchov wrote: > On Thu, Nov 12, 2015 at 02:52:01PM +0800, Michael W. Bombardieri wrote: > > > > ok for removing xfree from aucat? > > > > > > yes, ok ratchov; if later this causes me merges i'll find another > > > solution. Feel free to do the same in usr.bin/sndiod, as it's > > >

Re: sdhc(4) on APU2

> Date: Tue, 10 Nov 2015 20:28:24 + > From: Miod Vallat > > > The SDHC on this machine comes with a 64-bit BAR, so we need to fix > > that XXX. I did change the error handling a bit such that we give up > > after the first unmappable BAR. It seems multi-slot controllers are

Re: give cron a sensible default max load_avg for batch jobs

On 2015-11-14 04:28, Todd C. Miller wrote: > On Fri, 13 Nov 2015 16:45:44 -0700, Theo de Raadt wrote: > >>> This patch changes the default setting to 1.5 * >>> (number_of_cpus_in_system) instead, which I find better matches modern >>> behaviour. >> >> A larger number is sensible in this position.

give cron a sensible default max load_avg for batch jobs

Hi tech@, Inspired by the flurry of changes to cron(8) the last couple of days, I finally went to fix an issue that has bitten me numerous times over the years, since I'm a heavy user of batch(1) and at(1): When running a batch/at job, cron looks at the system's current load average to determine

Re: give cron a sensible default max load_avg for batch jobs

> This patch changes the default setting to 1.5 * > (number_of_cpus_in_system) instead, which I find better matches modern > behaviour. A larger number is sensible in this position. I would propose 8. I don't agree with a calculation like that; the amount of work a system can do should not be

Re: give cron a sensible default max load_avg for batch jobs

On Fri, 13 Nov 2015 16:45:44 -0700, Theo de Raadt wrote: > > This patch changes the default setting to 1.5 * > > (number_of_cpus_in_system) instead, which I find better matches modern > > behaviour. > > A larger number is sensible in this position. > > I would propose 8. I don't agree with a

Re: give cron a sensible default max load_avg for batch jobs

On 2015-11-14 00:45, Theo de Raadt wrote: >> This patch changes the default setting to 1.5 * >> (number_of_cpus_in_system) instead, which I find better matches modern >> behaviour. > > A larger number is sensible in this position. > > I would propose 8. I don't agree with a calculation like

Re: [patch] was: Re: login(3) routines data integrity patch

On 11/12/15 14:10, Ted Unangst wrote: Chris Turner wrote: >>> The attached patch calls fsync(2) on related FD's in the login(3) routines, which corrected the problem on my test machine, and imho might be a good idea in general. AFAIK it should not be necessary to call fsync() before close().

Re: MALLOC_STATS and pledge

On Fri, Nov 13, 2015 at 09:11:46AM +, David CARLIER wrote: > Hi all, > > I ve tried to discuss this point with Otto Moerbeek but he might be > very busy so I throw the topic here if you do not mind ... > > I have the habit to enable MALLOC_STATS but with the recent pledge > feature, it s

Re: MALLOC_STATS and pledge

> I ve tried to discuss this point with Otto Moerbeek but he might be > very busy so I throw the topic here if you do not mind ... > > I have the habit to enable MALLOC_STATS but with the recent pledge > feature, it s now difficult to debug some pledged applications with > MALLOC_OPTIONS=D as,

Re: MALLOC_STATS and pledge

> An idea would be to open the fd at init time, which should be early > enough for most cases (i.e. before the first pledge(2) call). Big > drawback is the open fd all the time until program exits. Keeping a fd open through libc runtime is not going to fly. It isn't just the fragility of it.

pledge("stdio") for arch(1)/machine(1)

This straightforward pledge("stdio") is one of the last uncommitted ones from Theo's big 'tame in userland' diff and seems to have been overlooked so far. Index: usr.bin/arch/arch.c === RCS file: /cvs/src/usr.bin/arch/arch.c,v

Tighter pledge(2) for nm(1)/size(1)

nm(1) was tamed shortly before the "exec" promise was introduced. The "proc exec" is necessary to cover `nm -C' which fork-exec's c++filt(1). Right after potential fork-exec, the original pledge "stdio rpath" is given (one could make that last pledge call in the file conditional on `issize' so