[PATCH] Option for mount_tmpfs to populate the volume after creation.

This patch adds an option -t template to mount_tmpfs, which populates the new tmpfs volume with a directory immediately after creation. Man page update included for explanation. Much of the code was grafted from newfs which implements this for mount_mfs (-P option). Suggestions, fixes,

Re: [PATCH] Option for mount_tmpfs to populate the volume after creation.

In the mount_tmpfs.8 diff, you talk about mfs... :) Landry Serves me right for coding while I'm sick. Revised diffbelow: Index: mount_tmpfs.8 === RCS file: /cvs/src/sbin/mount_tmpfs/mount_tmpfs.8,v retrieving revision 1.3 diff

Re: [PATCH] Option for mount_tmpfs to populate the volume aftercreation.

Original Message From: Otto Moerbeek o...@drijf.net To: bytevolc...@safe-mail.net Cc: tech@openbsd.org Subject: Re: [PATCH] Option for mount_tmpfs to populate the volume aftercreation. Date: Thu, 18 Sep 2014 10:54:34 +0200 On Thu, Sep 18, 2014 at 08:40:44AM +0100,

[no subject]

Yes. As it would seem, that was unintentional, possibly caused by a bad merge. I didn't pick this up as it worked on my system. It was thanks to Otto's messae re parsing changes that I managed to pick that up. I am working on a new diff which will be released some time within the next few

[PATCH] VIA CPU feature set recognition (amd64)

Hi, I noticed the following when trying to do some benchmarking for the padlock engine on a VIA Eden CPU using the openssl speed command on -current (as of 6 Sept) amd64: - machdep.xcrypt=0 (should be 15; like i386 port) - no hw.sensors.cpu?.temp (shows up on i386 port) - openssl speed ...

[PATCH] (amd64) VIA CPU feature set detection

Patch below allows the kernel (amd64) to detect CPU features (VIA PadLock, temperature sensors, etc.) on modern VIA Eden CPUs. My apologies for the previous substandard overly-verbose message. Index: sys/arch/amd64/amd64/identcpu.c

[PATCH] Allow bioctl(8) to recognise DUIDs (and such) for many operations

This patch allows bioctl(8) to perform operations on volumes using either the fully-qualified device path (eg. /dev/sd0a) or a valid DUID pointing to the RAID volume or device. Basically, anything that opendev(3) can open. Index: sbin/bioctl/bioctl.c

mount_tmpfs(8) MINOR man page correction

The manual page for mount_tmpfs(8) states that it was included in OpenBSD 5.4, when the first -release with tmpfs was 5.5. Corrected in the following diff: Index: sbin/mount_tmpfs/mount_tmpfs.8 === RCS file:

Re: bioctl -d: accept DUIDs

Whilst I mostly like this patch, and it appears to be much cleaner than the bodgy solution I came up with a few years back, perhaps there is something here worth mentioning: + snprintf(devname, sizeof(devname), %s%d, blkname, + DISKUNIT(bd-bd_dev)); TAILQ_FOREACH(sd,

Re: doas with a timeout

An easier and more reliable compromise would be running 'doas sh' and executing multiple commands in the shell that is root. Having said that, I am unsure if doas(1) uses the $HOME of the current user, or the user that the command is executed as. If $HOME is that of the current user, the

[PATCH] mount_tmpfs -P option for populating after mounting (simplified)

Hello, Although a patch like this was submitted before, this one is more "focused". It may be useful for those moving from MFS who use this option to pre-populate an MFS mount with a collection of files. This will refuse to work if the path specified for -P is not a directory. If the copy is

Re: ssl(8) kill "generating dsa server certificates"

Whilst not a developer per se, I don't see any reason why omitting the documentation for a feature that is present is a good idea, unless the feature is/will be removed. Perhaps just something like this: Index: ssl.8 === RCS file:

Re: ssl(8) kill "generating dsa server certificates"

I see. I guess people who really need DSA keys can figure this out from the general format of the other sections. Thanks for putting this into perspective. On Mon, 6 Jun 2016 14:57:54 +0100 Stuart Henderson wrote: > On 2016/06/06 23:52, bytevolc...@safe-mail.net wrote: >

Re: [PATCH] mount_tmpfs -P option for populating after mounting (simplified)

ping. On Sun, 13 Sep 2015 14:50:19 +0100 bytevolc...@safe-mail.net wrote: > Hello, > > Although a patch like this was submitted before, this one is more > "focused". It may be useful for those moving from MFS who use this > option to pre-populate an MFS mount with a collection of files. This >

Re: www.openbsd.org/cgi-bin/man.cgi

I was thinking more of having a Javascript implementation of OpenBSD so that you could type the 'man' command to get the page you are after. It will only increase the size of the page by about 400MB, and hard disk and CPU space is cheap. And everyone has infinite bandwidth internet. On Fri, 25

Re: [PATCH] Allow softraid crypto to work with write-protected keys

ping On Wed, 18 May 2016 12:14:50 +0100 bytevolc...@safe-mail.net wrote: > My apologies for the noise; the previous one was the wrong revision > (r1.126 instead of 1.127) because both patches look similar; here is > the most recent catch: > > Index: sys/dev/softraid_crypto.c >

Re: [PATCH] Allow softraid crypto to work with write-protected keys

I have also noticed that bioctl reports the key disk as incorrect. I initially thought it was my patch, but it seems to be wrong whether or not my patch is applied. In fact the contents of the disk do not change at all: # bioctl softraid0 Volume Status Size Device softraid0 0

[PATCH] Allow softraid crypto to work with write-protected keys

Softraid currently opens the key disk as read + write. This isn't necessary when just *reading* from the key disk. This patch allows for softraid crypto to mount volumes with write-protected keydisks (eg. Kanguru Flash Blu: https://www.kanguru.com/storage-accessories/flash-blu30.shtml). Also

Re: [PATCH] Allow softraid crypto to work with write-protected keys

Ted Unangst wrote: > i removed these last two lines, since they were incorrect. thanks for spotting > that. however the vop_close at the end still needs updating. Thanks Ted, Also I found another stray VOP_CLOSE() setup. I have also put in the VOP_OPEN(vn, FREAD, ...) as I am not sure about

Re: [PATCH] Allow softraid crypto to work with write-protected keys

My apologies for the noise; the previous one was the wrong revision (r1.126 instead of 1.127) because both patches look similar; here is the most recent catch: Index: sys/dev/softraid_crypto.c === RCS file:

Re: OFW/FDT regulator API

I have to admit, it's a bit shocking that VOLTAGE REGULATORS have to be exposed to the software in the first place. Just imagine a bug in some OS or firmware causing the voltages to spike up and fry the hell out of a device. I guess that's modern-day hardware design for you. Mark Kettenis

syspatch(8): How to install patches?

Hello, In the manual page for syspatch(8), it provides a list of options, yet does not specify how to invoke it for fetching and installing the latest patches. To avoid this confusion, it is worth adding a line like this: "When invoked without options, syspatch(8) will fetch and install the

Re: syspatch(8): How to install patches?

On Wed, 9 Nov 2016 09:58:51 +0100 Antoine Jacoutot wrote: > On Wed, Nov 09, 2016 at 07:12:38PM +1100, bytevolc...@safe-mail.net > wrote: > > Hello, > > > > In the manual page for syspatch(8), it provides a list of options, > > yet does not specify how to invoke it for

Re: regarding OpenSSL License change

... > If we do not hear from you, we will assume that you have no objection. So, they will claim that, by not responding, the recipient agreed. Some jurisdictions I am aware of accept verbal contracts or this kind of written contracts, since civil proceedings will not be held up to a high

Re: regarding OpenSSL License change

On Thu, 23 Mar 2017 20:51:06 -0600 "Theo de Raadt" wrote: > Dude, you are being melodramatic > > it is great that someone found a way to convert between licenses. > > AGPL -> GPL -> ISC -> PD > > thumbs up to the people who found a shortcut > Now this is genius.

Re: [patch 1/2] doas(1): Moved some parsing from env.c into parse.y

On Wed, 15 Mar 2017 13:22:53 -0400 "Ted Unangst" wrote: ... > > 1. Loops - Use C99 style initialisation? > > for(int i = 0; i < monsters; i < 666) > > No. > > > 3. Anything of major concern. > > Adding a new character to the lexer potentially breaks existing >

Re: [patch 1/2] doas(1): Moved some parsing from env.c into parse.y

On Wed, 15 Mar 2017 20:15:26 -0400 "Ted Unangst" wrote: > Did I get it backwards? If you have setenv { HERE= there }, your diff > changes behavior. > Now I see where you are coming from. It's meant to empty $HERE, and copy $there. Thanks, I'll look into this.

[patch 1/2] doas(1): Moved some parsing from env.c into parse.y

Instead of having to use another 1KB buffer just to figure out where the '=' sign is, use the parser infrastructure already present. Also allows for variable timeout option. Another (negligible) advantage: if one day someone wants to change the maximum line length, they only need to do so in one

[patch] doas(1): use a #define for the environment variable name length limit

No functional or user-visible changes here. On that note, where did the "1024" (1023-char) come from? Is there anyone who has environment variables whose name goes near 1023 chars? Index: usr.bin/doas/env.c === RCS file:

Re: patch: mv(1): Add -p flag to preserve time stamps for moved directories

Sorry I was copying this out from a VM, so I ended up typing it up wrong here: $ mkdir Foo $ touch -t 2101 Foo $ ls -dlT Foo drwxr-xr-x 2 bob bob 512 Jan 1 00:00:00 2000 Foo $ ls -dluT Foo drwxr-xr-x 2 bob bob 512 Jan 1 00:00:00 2000 Foo $ mkdir Bar $ mv Foo Bar/ $ ls -dlT Bar/Foo

Re: patch: mv(1): Add -p flag to preserve time stamps for moved directories

On Tue, 11 Apr 2017 16:54:29 +0200 Ingo Schwarze wrote: > Hi, > > bytevolc...@safe-mail.net wrote on Fri, Apr 07, 2017 at 12:25:10PM > +1000: > > > Although mv(1) will preserve atime and mtime for moved directories > > if moved to a different file system, it doesn't preserve

Re: patch: mv(1): Add -p flag to preserve time stamps for moved directories

On Tue, 11 Apr 2017 19:39:28 -0700 Philip Guenther wrote: > The 'issue' is that he's changing the parent of a directory and that > means it has to update the ".." link inside the directory, so it > alters the directory contents and the mtime is thus updated. That explains a

Re: patch: mv(1): Add -p flag to preserve time stamps for moved directories

On Tue, 11 Apr 2017 16:41:16 -0600 "Theo de Raadt" wrote: > > Note that I have noatime on this FS. > > Maybe we should remove this broken feature. > I would love to know what is broken about it, so I can investigate this and disable it on my systems if it's too risky

Re: newsyslog timestamp

Is it worth making newsyslog use the syslog API instead of directly writing to the top of the file? Perhaps even integrating this functionality into syslogd so it can use the existing infrastructure, and LOG_SYSLOG facility, fork+privsep style: [syslogd]->|->[syslogd:logger]

Re: [patch 1/2] doas(1): Moved some parsing from env.c into parse.y

Hello Philippe, On Thu, 16 Mar 2017 10:19:12 -0400 Philippe Meunier wrote: > Ted Unangst wrote: > >Did I get it backwards? If you have setenv { HERE= there }, your diff > >changes behavior. > > Speaking from the peanut gallery here, but I find this syntax rather >

Re: [patch] doas(1): use a #define for the environment variable name length limit

On Wed, 05 Apr 2017 15:07:40 -0400 "Ted Unangst" wrote: > bytevolc...@safe-mail.net wrote: > > No functional or user-visible changes here. > > On that note, where did the "1024" (1023-char) come from? Is there > > anyone who has environment variables whose name goes near

patch: mv(1): Add -p flag to preserve time stamps for moved directories

Although mv(1) will preserve atime and mtime for moved directories if moved to a different file system, it doesn't preserve them when moved in the same file system. Upon looking around, it appears to be standard POSIX behavior, as the utility is meant to perform a rename() and exit. This patch

Re: Basic SHA3 support

I also use the sha512 command on a regular basis, and notice a performance improvement (compared to sha256) with amd64 systems. On Wed, 10 Jan 2018 17:10:40 + (GMT) Tom Cosgrove wrote: > >>> "Todd C. Miller" 10-Jan-18 16:28 >>> > > > > On Wed, 10 Jan

Re: Basic SHA3 support

On Wed, 10 Jan 2018 20:32:30 -0700 "Theo de Raadt" wrote: > > I also use the sha512 command on a regular basis, and notice a > > performance improvement (compared to sha256) with amd64 systems. > > But is /bin the place to put a performance improving command? > > No.