Sorry for the delay. LGTM.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 29 2019
Aug 21 2019
Resolving stalemate.
Aug 12 2019
Let me go back to the beginning in an attempt to unravel this. Let's start with Conrad's question:
"Isn't changing the output of w a POLA violation?"
Jul 4 2019
Jun 30 2019
Jun 29 2019
Use sx instead of mtx to allow M_WAITOK allocations
Jun 24 2019
Mar 23 2019
Mar 22 2019
Mar 9 2019
Mar 5 2019
Yeah, I don't like the way we now have the master files. I think I was too much focussed on keeping the file size small and opted to compress, followed by uuencode. But it's a real pain to work with. For one, you can't diff the rebased files after a code change and see if the new behavior matches the expectation. And on top of that, diffs tend to be much bigger than a one-liner of the hexdump output.
Mar 3 2019
Jan 26 2019
Thanks for pointing out that OpenSSL 1.0.x needs to be supported.
OpenIKED 2.1 has support for OpenSSL 1.0.x and OpenSSL 1.1.x.
Upgrade to openiked-2.1
Jan 20 2019
May 2 2018
Feb 23 2018
This is opposite the direction taken already. The low-level console is defined in terms of hardware resources only. The uart(4) driver will map the low-level console to the newbus device during bus enumeration. The unit number is not a hardware resource. It's a newbus device property.
Feb 17 2018
LGTM.
Feb 5 2018
I'm ok with the changes. I'll trust Ed to give others a chance to chime in. Speculatively accepting the revision on everyone's behalf.
Dec 2 2017
Nov 27 2017
Nov 19 2017
Oct 6 2017
Sep 22 2017
Sep 21 2017
Sep 14 2017
I feel that using GEOM::media as a way to signal a label change is missing the more fundamental problem: the code change is based on the assumption that labels can't change, which ae@ showed is false.
Sep 5 2017
Aug 31 2017
Aug 23 2017
LGTM...
Two comments:
- I see that there's an unvis(3) function as well. That seems like a good way to handle escape sequences in read_word() and not have callers of read_word() handle escape characters.
- makefs needs to be portable. Do you know if vis(3) exists on macOS and Linux?
Jun 9 2017
First the quick answer: The pf_state structure as sent by the INS, DEL and UPD actions is not a multiple of 4-bytes on amd64. All the pfsync structure are indeed.
Jun 8 2017
The updated diff addresses your concern and eliminates incompatibilities. Your comment tells me that you haven't seen the updated diff...
Jun 6 2017
If there are no objections, I'll commit this in a few days.
May 23 2017
Don't change the version in the header (i.e. keep at 5), and
instead use the subsequent _pad field for a revision. The
revision allows minor changes to the definitions while not
breaking compatibility with previous revisions.
In D10863#225094, @glebius wrote:Is this part of a bigger change? What's the final goal.
May 22 2017
May 11 2017
May 10 2017
May 3 2017
May 2 2017
May 1 2017
Apr 24 2017
Apr 18 2017
Apr 15 2017
Apr 12 2017
Mar 3 2017
Mar 2 2017
Already fixed.
I'm seeing this with a slightly older 11-stable. I see that r305055 has been MFC'd as r313129 on 2017-02-02. which means the fix is not present on the system I see it in. Both my up-to-date -current and -stable systems seem to work (see example below). So it looks the problem was already fixed!
Feb 27 2017
Feb 25 2017
Feb 20 2017
Going for the workaround I see! :-)
Feb 5 2017
Feb 2 2017
Got it! Thanks for the explanation.
Jan 31 2017
First of all: You may want to change root_mount_rel() as well: h cannot be NULL anymore. A KASSERT would be appropriate...
Jan 19 2017
I don't want to assume I remember all the details with respect to compiling libc from a different locations, but what I recall is that it's only about building libc using a different makefile that lives in a different directory and thus having the object files go to a different object directory. Thus any mention of ${.CURDIR} had to be replaced with LIBC_SRCTOP and LIBC_SRCTOP was effectively set to ${SRCTOP}/lib/libc.