Re: efiboot 240x56 mode

Hi, On Sat, 12 Mar 2016 10:22:13 +0100 Matthieu Herrb wrote: > a collegue of mine recently tried to get OpenBSD running on an HP E820 > laptop. Apparently this machine is UEFI only and its BIOS only works > in a 240x56 text mode. The original efi_video_init() is to switch the

Re: Optimizing chmod(1)

Adam Thompson wrote: > > On 16-03-13 11:11 PM, Michael McConville wrote: > >It seems that chown(1) will write to a file even if it already has the > >desired ownership. The below patch causes it to skip the write when > >there would be no change. The best I could tell, the fts_read(3) and >

Re: queue.3, tree.3 - SEE ALSO

On Sun, Mar 13, 2016 at 10:59:31AM +0100, Michal Mazurek wrote: > Refer to tree.3 from queue.3, and the other way around. > fixed, thanks. jmc > Index: share/man/man3/queue.3 > === > RCS file: /cvs/src/share/man/man3/queue.3,v >

Re: COLUMNS handling

So COLUMNS and LINES are not needed for automatic correct behavior in a modern environment... So we still have the questions: useful to restrain programs from stomping all over the terminal which is what POSIX mandates ? Should we jump that way ?

Re: opendev(3) tweak

On Mon, Mar 14, 2016 at 10:19:53PM +0100, Theo Buehler wrote: > On Thu, Mar 10, 2016 at 12:52:35PM +0100, Marc Espie wrote: > > Already shown to a few people, but since pledge(2) aborts on non-dev, let's > > check upfront that we're of the right type. > > > > I don't think this requires a bump.

Re: opendev(3) tweak

On Thu, Mar 10, 2016 at 12:52:35PM +0100, Marc Espie wrote: > Already shown to a few people, but since pledge(2) aborts on non-dev, let's > check upfront that we're of the right type. > > I don't think this requires a bump. It doesn't really change the interface, > just makes it stricter. > If

Re: spamd - blacklists

So I'd say remove it until we decide on an alternative :) On Mon, Mar 14, 2016 at 10:27 AM, Stuart Henderson wrote: > On 2016/03/14 10:20, Michael McConville wrote: >> Craig Skinner wrote: >> > Hi Hans, >> > >> > On 2016-03-14 Mon 11:49 AM |, hans wrote: >> > > On Mar 13

Re: hexdump(1) - unneeded headers

This was sent during the freeze. On 14:13:40, 8.02.16, Michal Mazurek wrote: > These headers appear to be unneeded: > > Index: conv.c > === > RCS file: /cvs/src/usr.bin/hexdump/conv.c,v > retrieving revision 1.10 > diff -u -p

Re: hexdump(1) - tidy declarations

This was sent during the freeze. On 15:04:28, 8.02.16, Michal Mazurek wrote: > Move some declarations out of hexdump.h > Mark some declarations as __dead or static > Remove a commented out declaration > Convert some spaces to tabs > > Index: display.c >

Re: COLUMNS handling

On Mon, Mar 14, 2016 at 5:32 AM, Martin Natano wrote: > On Mon, Mar 14, 2016 at 10:57:36AM +0100, Marc Espie wrote: >> >> So, does it make sense to put COLUMNS and SIZE forward ? >> I think this is the first important question to ask... >> >> (I remember having COLUMNS and

Re: malloc: 1st small step in long way to multiple pools

This is working fine for me on armv7 and macppc so far.

Re: arm: purge arm8 - and maybe more?

On Wed, Mar 09, 2016 at 09:14:06AM +0100, Patrick Wildt wrote: > On Wed, Mar 09, 2016 at 01:28:55PM +1100, Jonathan Gray wrote: > > On Tue, Mar 08, 2016 at 10:59:42PM +0100, Patrick Wildt wrote: > > > Hi, > > > > > > I'd like to get some opinions on this. ARM8 has probably never ever > > > been

Re: sdhc: don't always compile the pci attachment driver

On Fri, Mar 04, 2016 at 10:32:18PM +0100, Patrick Wildt wrote: > Hi, > > if you attach sdhc, you automatically compile the pci attachment driver, > even if there's no "sdhc* at pci?" in the config. This might fail on > architectures that don't have pci compiled in. > > If I'm not completely

Re: spamd - blacklists

On 2016/03/14 10:20, Michael McConville wrote: > Craig Skinner wrote: > > Hi Hans, > > > > On 2016-03-14 Mon 11:49 AM |, hans wrote: > > > On Mar 13 18:56:00, mm...@mykolab.com wrote: > > > > hans wrote: > > > > > The link to "the place to search for blacklists" is dead. > > > > > > > > Might be

Re: some more vlan protocol defines

On 2016/03/14 21:13, David Gwynne wrote: > this adds macros to describe the min and max valid vlan ids. > > this will be used in upcoming checks of the configured values from > userland. > > ok? Hmm - I think there may be something about using tag 0 to allow sending packets on an "untagged"

Re: New scheduler for OpenBSD

On 14/03/16(Mon) 16:05, Michal Mazurek wrote: > On 04:41:05, 13.03.16, Juan Francisco Cantero Hurtado wrote: > > Here are the commands: > > ... > > ffmpeg > > ... > > Thank you for this. > > ffmpeg runs differently from gcc or make - it creates a lot of threads. > I can verify that it is indeed

Re: New scheduler for OpenBSD

On 16:35:49, 13.03.16, Martin Pieuchot wrote: > On 12/03/16(Sat) 17:36, Michal Mazurek wrote: > > [...] > > Some notes: > > > > Chrome is still not very usable. > > Are you wanting to improve the browser experience on OpenBSD? If that's > your goal then I'd suggest you to start by analysing

Re: Optimizing chmod(1)

On 16-03-13 11:11 PM, Michael McConville wrote: It seems that chown(1) will write to a file even if it already has the desired ownership. The below patch causes it to skip the write when there would be no change. The best I could tell, the fts_read(3) and fchownat(3) logic agree on whether to

Re: New scheduler for OpenBSD

On 04:41:05, 13.03.16, Juan Francisco Cantero Hurtado wrote: > Here are the commands: > ... > ffmpeg > ... Thank you for this. ffmpeg runs differently from gcc or make - it creates a lot of threads. I can verify that it is indeed slower. Instead of spending 2 seconds in 'system' it takes 30 or

Re: spamd - blacklists

Craig Skinner wrote: > Hi Hans, > > On 2016-03-14 Mon 11:49 AM |, hans wrote: > > On Mar 13 18:56:00, mm...@mykolab.com wrote: > > > hans wrote: > > > > The link to "the place to search for blacklists" is dead. > > > > > > Might be better to replace it than to remove it. > > > > Sure. Any

Re: spamd - blacklists

Hi Hans, On 2016-03-14 Mon 11:49 AM |, hans wrote: > On Mar 13 18:56:00, mm...@mykolab.com wrote: > > hans wrote: > > > The link to "the place to search for blacklists" is dead. > > > > Might be better to replace it than to remove it. > > Sure. Any suggestions? > Some DNSRBLs are available as

Re: COLUMNS handling

On Mon, Mar 14, 2016 at 10:57:36AM +0100, Marc Espie wrote: > > So, does it make sense to put COLUMNS and SIZE forward ? > I think this is the first important question to ask... > > (I remember having COLUMNS and LINES hardcoded in my old, old .profile > around SunOS4... we can probably assume

some more vlan protocol defines

this adds macros to describe the min and max valid vlan ids. this will be used in upcoming checks of the configured values from userland. ok? Index: if_ether.h === RCS file: /cvs/src/sys/netinet/if_ether.h,v retrieving revision

Re: spamd - blacklists

On Mar 13 18:56:00, mm...@mykolab.com wrote: > hans wrote: > > The link to "the place to search for blacklists" is dead. > > Might be better to replace it than to remove it. Sure. Any suggestions? > > Index: spamd.conf > > === > >

Re: COLUMNS handling

On Mon, Mar 14, 2016 at 01:38:48AM -0600, Anthony J. Bentley wrote: > COLUMNS handling in our tree is inconsistent. > > POSIX specifies that if COLUMNS is a valid value (read: 1 or greater), > it takes precedence; otherwise, width is handled in an unspecified > manner. > > Most programs follow

vi: add COLUMNS/LINES validity checks

vi is kind of weird about COLUMNS/LINES handling. For one, it doesn't do any error checking: $ COLUMNS=a vi Floating point exception (core dumped) The manpage also claims that COLUMNS supersedes everything else. This is true... unless you ^Z and then unsuspend, at which point it uses

COLUMNS handling

COLUMNS handling in our tree is inconsistent. POSIX specifies that if COLUMNS is a valid value (read: 1 or greater), it takes precedence; otherwise, width is handled in an unspecified manner. Most programs follow COLUMNS, TIOCGWINSZ if that fails, and use 80 if that fails. Some do TIOCGWINSZ,

pledge: resolvpath() with relative path inside chroot

Hi, The resolvpath() function in kern_pledge.c is used for wl_paths (whitelisted-paths). It permits to obtain a full resolved path (absolute and chroot-agnostic) from a path supplied by user in order to check it against list of whitelisted paths. The order of the operations inside the function