Interesting. I just tested, and if I boot my machine while interface is on, kld_list and buffer_ms together do the trick. I mean, jack_iodelay reports exactly same latency as if I loaded the module, set buffer_ms and then turned on the interface. Maybe my interface is slow to respond initially, so sysctl has time to kick in? Anyway, if I were to do it differently, what should I do? Load module and set buffer_ms in loader.conf?

A misunderstanding. I though you wanted me to make sure there are no reconnects. Anyway, loading the driver first, then setting buffer_ms and then turning on the interface yields the following results

period = 192
buffer_ms = 1
  690.921 frames     14.394 ms total roundtrip latency
	extra loopback latency: 306 frames
	use 153 for the backend arguments -I and -O

Now this is a great improvement! Can we document it somewhere? Suggesting, for example, to put kld_list+=snd_uaudio and then set buffer_ms as any other sysctl? In my oppinion, if we spent so much time figuring out how to properly do the measurement, I'm sure other people will need help with their setup, too, so why not make it easier for them and put this into snd_uaudio(4).

I didn't answer about re-plugging. No, the interface is always connected and I don't touch the cables.

I see what you mean. I tested with buffer_ms of 1 and 8 and I get almost exact numbers:

period = 192

I missed 4ms request from you, so here are those measurements

Main branch
-----------
hw.usb.uaudio.buffer_ms = 4
period = 768
  3337.952 frames     69.541 ms total roundtrip latency
	extra loopback latency: 1033 frames
	use 516 for the backend arguments -I and -O

Thank you for the explanation. I took the measurement and I tried to get the lowest latency without jitters, so here is the complete measurement.

Main branch
-----------
hw.usb.uaudio.buffer_ms = 2

Sorry for the delay, I got sick (again). Anyway, it took me a while to figure out what's going on. As I didn't have speakers on, I didn't notice there are jitters, that's why the numbers don't match. I took similar measurements with higher period size in jack and these are the results

Main branch
-----------
hw.usb.uaudio.buffer_ms = 2

An example

Ah, so, single argument with quotes. If broken into multiple lines with "\" it makes fwget's output weird, hence one huge line.

It would be better if addpkg supported multiple arguments, but with current implementation we have to use multiple invocations.

I ran jack_iodelay with same buffer_ms value and these are the results:

Florian's patch is superior to this one, hence closing.

I finally found the time to test this patch. I'm running CURRENT and I only have Behringer XR18 at my disposal. First test I ran was lowering the buffer_ms to 1 and just playing audio for few hours. I didn't tweak virtual_oss parameters or anything, and audacious was using virtual_oss. Not a single jitter, glitch or xrun in those few hours, no audible defects of any kind. In the following days I intend to test the latency with jack_iodelay.

In D41627#949637, @mav wrote:

I am sorry, but once again: in this patch you change allowed minimum, but do not change the default on line 99, right?

I guess heat got to my head :) Thank you, good catch! Update is coming.

In D41627#949189, @mav wrote:

After your initial commit Hans reduced the default value from 8ms to the minimum of 2ms. I wonder if it is still OK or you'd like to reduce default also.

As a disclaimer, I know very little to nothing about USB.

If you're going to change format, why not use tree, as it feels natural for sysctl. One existing example would be dev.pcm.<number> so following that, we could have security.mac.ipacl.<jid>.<rule> and .family and .address (or maybe .range) as leafs. It is not set in stone that it has to be like that, but given it's sysctl, it feels more natural to me, so please give it a thought. Also, as it is about jail, it would also feel more natural to have this tunables under security.jail.<jid>

This patch fails to apply to CURRENT. I am using dhcpcd-10 since it was released (and used previous versions) for DHCP, SLAAC and DHCPv6, all on the same network. That's the closest to testing I can get in current state. If this patch is updated I would love to test it. Of course, if updating patch is required, I would love to do it, but at this point I'm not sure I know how.

Is there something we can do to make dhcpcd part of 14.0-RELEASE besides testing this patch?

Added kqueue/kevent example and made the choice of select/poll/kqueue selectable on runtime.

The poll(2) part is added

I you use git format-patch -1 -U9999 and apply it with git am <patch>, you get the whole commit with the message. Not strictly needed, but makes life easier.

Add FILES section to jail(8) and add -F option to usage() function.

Save original value of cfname and restore it after handling glob config.

Thank you for detailed review. I omitted the change for the style, as almost all of them were already present before my change, like not having {} on if. I personally don't have preferences for style so I'll do whatever maintainer thinks is right. I would like to keep style changes out of this patch, if possible.

Sort the includes.

In D38826#884016, @jlduran_gmail.com wrote:

I like the overall idea, thank you for adding more conf.ds to FreeBSD!

Something I do not understand: My "dormant", cron-initiated jails will always start upon boot (i.e., /etc/jail.anotherjail.conf, while anotherjail not in jail_list)?

Regarding the code itself, wouldn't it be better to create a function, something like:

all_jail_confs()
{
	local jail_conf_locations

	jail_conf_locations="$jail_conf $jail_conf_dir/*.conf /etc/jail.*.conf"
	if [ -f "$1" ]; then
		jail_conf_locations="$1 $jail_conf_locations"
	fi

	cat $jail_conf_locations 2>/dev/null
}

And use it instead of repeating the same code in 5 places?

I think that would not be the simplest example, and I was aiming at simplicity. My idea with audio, MIDI and combined example was to make it as simple as possible. Next examples are going to be harder topics: handling 24bit audio in different endianess, ability to choose between select, poll and kqueue and combining it all into one big example at the end. That being said, can we keep this example as is?

I did a little research and it turns out that SIOCSPFXFLUSH_IN6 is only supported on FreeBSD and derivatives like DragonflyBSD so the check if it's defined is practically check if it's running on FreeBSD. As NetBSD removed it and OpenBSD doesn't have it, what will happen if we remove the SIOCSPFXFLUSH_IN6 call from dhcpcd?

As nd6.c states /* flush all the prefix advertised by routers */ and route that dhcpcd removes is definetely not advertized by any router but set as part of ifconfig re0 inet6 ...., maybe the bug is on FreeBSD side?

Please note there's a bug in dhcpcd and/or FreeBSD: https://github.com/NetworkConfiguration/dhcpcd/pull/121. Could somebody more experienced with networking take a look, please? In short, without the mentioned PR, dhcpcd removes IPv6 routes from bridge0 interface while re0 is being configured. Thank you!

In D36195#822271, @pstef wrote:

I think it's just a matter of you saying how you want to be referred to in the author field of the git commit :) But I think it requires a "name <email>" format.

I though "git format-patch" will do the right thing here. But anway "Goran Mekić <meka@tilda.center>" is prefered.

As for formatting, this is the output that indent(1) produced. Can you tell me what would make it better?

To be honest I don't know how the process works. Can you advise, please?

Is there anything I can improve? Did I miss something?

Licence and install fixed

My apologies, I missinterpreted the "inline" part.

Make internal functions static

I fixed all from previous comments, except printf formating. I tried to mimic pf.c: https://cgit.freebsd.org/src/tree/sys/netpfil/pf/pf.c#n646 where arguments are on the next line 4 spaces indented to the right relative to start of function name. I also read style(9) one more time and I can't find what I did wrong, so if it's still wrong, please advise.

I didn't even know indent exists. Thank you!

Nitpicking is good, it keeps docs perfect.

As only one object from nvlist is explained, I decided to go with "an nvlist object".

Update the patch with suggestions by Ka Ho Ng. Sorry it took so much time (vaccine problems), and forgive me if I do something wrong on reviews as it is the first time I'm using it.

Yes, it's still relevant. I'm very slow at progress on PF+Dummynet integration, but I am working on it, and dummynet not depending on IPFW is essential.