imp (Warner Losh)
User

Projects

User Details

User Since
Jun 2 2014, 4:20 PM (164 w, 1 d)

Recent Activity

Yesterday

imp added a comment to D11730: jedec_ts: add many more devices from various vendors.

Generally, this looks good to my eye. I think the masks are overkill, but that comes from my experience in pci land where they were over-used and under-needed.

Tue, Jul 25, 2:12 PM
imp committed rP446556: Port-wise change :.
Port-wise change :
Tue, Jul 25, 6:04 AM

Mon, Jul 24

imp committed rS321429: fix typo.
fix typo
Mon, Jul 24, 6:10 PM

Sat, Jul 22

imp added a comment to D11589: Print more info when super blocks don't match, implement ability to ignore mismatches..

I would posit that fsck is the wrong place to replicate newfs' calculations, unless there's some value that's added that I'm not seeing.

Sat, Jul 22, 11:39 PM
imp added a comment to D11589: Print more info when super blocks don't match, implement ability to ignore mismatches..

If newfs was used with default settings, and the partition was not resized, then alternate superblocks can be found by fsck using the same calculation as was done by newfs.
The problematic case is the e.g. resizing of the partition and the filesystem after initial filesystem creation, since alternate superblocks with stale content would be found.

Sat, Jul 22, 1:48 PM

Wed, Jul 19

imp accepted D11636: efirt: restrict visibility of EFIABI_ATTR-declared functions.

This also works, and I like the larger area protect by _KERNEL.

Wed, Jul 19, 1:52 PM
imp accepted D11633: Include ARCH_FLAGS in CFLAGS when building modules..

Should have been done when the kernel side of this was committed.

Wed, Jul 19, 1:45 PM

Tue, Jul 18

imp added inline comments to D11636: efirt: restrict visibility of EFIABI_ATTR-declared functions.
Tue, Jul 18, 5:27 PM
imp accepted D11636: efirt: restrict visibility of EFIABI_ATTR-declared functions.

kib/imp feedback: detect old compiler version rather than move decls.

I checked that this compiles with gcc 4.2 WITHOUT_MODULES=efirt, and with clang 4.0 (plain, including efirt). I am still testing gcc > 4.4.

I guess clang also defines __GNUC__ as the clang build failed without the clang check. I don't have a way to check __INTEL_COMPILER, I am just following sys/sys/cdefs.h on that one.

Tue, Jul 18, 5:19 PM
imp added a comment to D11636: efirt: restrict visibility of EFIABI_ATTR-declared functions.
In D11636#241063, @imp wrote:

The proper solution then is what both kib and I are saying: add the proper ifdef so it isn't included when compiling with the old compiler. The declarations belong here as they aren't machine specific. The old compiler is going away, and it makes no sense to move something out of the way when we'll just move it back for arm64 EFIRT support later. Just ifdef it out for gcc < 4.4. We'll be dropping support for that in 12 most likely and it's a lot easier to delete a couple of lines than to move it around.

Oh, yeah, I'm happy to do that. I got the wrong impression from the previous comment I guess. I'll update this shortly with the compiler version detection.

Tue, Jul 18, 3:21 PM
imp added a comment to D11636: efirt: restrict visibility of EFIABI_ATTR-declared functions.
In D11636#241051, @imp wrote:

IMHO, This is completely bogus.

We do not support and cannot support building anything using EFI with the old gcc compiler. Better to have a check to see if it is the old gcc compiler and #error, or like we do for the loader build, exclude those modules when built with old gcc.

There will be other architectures where this code is used, like arm64, once the VM stuff is done for them.

Do not commit this code.

What's the use case that this is even included with gcc 4.2.1?

This isn't to build efirt with gcc 4.2, it's to NOT build it!

The EFIABI_ATTR decls currently are visible even when not compiling efi code, which breaks the gcc 4.2 build even when specifying WITHOUT_MODULES=efirt. E.g.

cc [...] /usr/src/freebsd/sys/amd64/amd64/machdep.c
cc1: warnings being treated as errors
In file included from /usr/src/freebsd/sys/amd64/amd64/machdep.c:65:
/usr/src/freebsd/sys/sys/efi.h:146: warning: 'ms_abi' attribute directive ignored [-Wattributes]

And also some userland code (don't recall exactly what, some ioctl code). So either the decls need to be hidden from in-tree gcc somehow, or it will no longer work for amd64 buildkernel or buildworld.

Tue, Jul 18, 3:06 PM
imp requested changes to D11636: efirt: restrict visibility of EFIABI_ATTR-declared functions.

IMHO, This is completely bogus.

Tue, Jul 18, 1:59 PM

Mon, Jul 17

imp added a comment to D11628: Add SUBDIR_SORTED, a generic mechanism for ordering subdirectories and apply option to *bin/Makefile.
In D11628#240890, @ngie wrote:
In D11628#240879, @imp wrote:

Would SUBDIR_UNSORTED make more sense? Of course SUBDIR_PARALLEL likely should wither and die for a similar reason...

I don't think SUBDIR_UNSORTED would make sense to be honest. That sounds like an opt-out feature that might break downstream consumers of bsd.subdir.mk. I wanted to make this opt-in so projects that used bsd.subdir.mk and didn't use SUBDIR_PARALLEL wouldn't break after this change. FreeBSD has several Makefiles in gnu/ for instance at some point in time that were also affected by this, IIRC, so I expect downstream consumers to be more likely to have Makefiles which might be affected by the converse behavior if it was globally enabled and available as an opt-out feature.

Mon, Jul 17, 11:24 PM
imp added a comment to D11628: Add SUBDIR_SORTED, a generic mechanism for ordering subdirectories and apply option to *bin/Makefile.

Would SUBDIR_UNSORTED make more sense? Of course SUBDIR_PARALLEL likely should wither and die for a similar reason...

Mon, Jul 17, 6:31 PM
imp added a comment to D11589: Print more info when super blocks don't match, implement ability to ignore mismatches..
In D11589#240652, @kib wrote:
In D11589#240165, @imp wrote:

We have had an issue, still not completely root caused, where the last alternate supreblock is bad (all zeros, either due to enemy action, or a newfs run gone awry). We needed some way to proceed with the fsck anyway to help track down the problem. In looking at that problem, the unused proto became obvious, so that was fixed as well. So the CHK changes are to give more data about how they don't match, and the prompt is to allow fsck to proceed in the face of this error to find out if it is localized to that one block, or more systemic. I have the two logical commits separated out in my git tree that I'll commit from.

Mon, Jul 17, 1:51 PM

Fri, Jul 14

imp added a comment to D11589: Print more info when super blocks don't match, implement ability to ignore mismatches..
In D11589#240154, @kib wrote:

Can you remind me the context where the previous discussion occur ? I do not remember a bit about it, sorry.

Fri, Jul 14, 3:51 PM
imp closed D10247: Add CAM passthrough for NVMe by committing rS320984: This adds CAM pass(4) support for NVMe IO's. Applications indicate.
Fri, Jul 14, 2:52 PM
imp committed rS320984: This adds CAM pass(4) support for NVMe IO's. Applications indicate.
This adds CAM pass(4) support for NVMe IO's. Applications indicate
Fri, Jul 14, 2:52 PM

Thu, Jul 13

imp retitled D11589: Print more info when super blocks don't match, implement ability to ignore mismatches. from Print more info when super blocks don't match, implement ability toignore mismatches. to Print more info when super blocks don't match, implement ability to ignore mismatches..
Thu, Jul 13, 10:45 PM
imp retitled D11589: Print more info when super blocks don't match, implement ability to ignore mismatches. from Print more info when super blocks don't match, implement ability to ignore mismatches. to Print more info when super blocks don't match, implement ability toignore mismatches..
Thu, Jul 13, 10:44 PM
imp updated the diff for D11589: Print more info when super blocks don't match, implement ability to ignore mismatches..

Updating D11589: Print more info when super blocks don't match, implement ability to

ignore mismatches.

Thu, Jul 13, 10:42 PM
imp created D11589: Print more info when super blocks don't match, implement ability to ignore mismatches..
Thu, Jul 13, 10:41 PM

Wed, Jul 12

imp added a comment to D9680: Increase EFI MSDOSFS image size to 512Kib.

Why not 50MB instead of 512kb? That's stupidly small and precludes any and all future use of UEFI programs as well as boot block bloat. bz2 compressed, the size difference is trivial.

Wed, Jul 12, 2:52 PM

Tue, Jul 11

imp committed rD50471: Document 1200038: MMCCAM..
Document 1200038: MMCCAM.
Tue, Jul 11, 2:17 AM

Mon, Jul 10

imp committed rS320879: Bump to FreeBSD_version to 1200038 for MMC CAM.
Bump to FreeBSD_version to 1200038 for MMC CAM
Mon, Jul 10, 9:55 PM
imp committed rS320878: Move mmc_parmas to the end of the structure for better compatability..
Move mmc_parmas to the end of the structure for better compatability.
Mon, Jul 10, 9:55 PM
imp committed rS320877: Kill some unnecessary noise..
Kill some unnecessary noise.
Mon, Jul 10, 9:38 PM
imp committed rS320860: Include opt files in the kernel with "" instead of <>..
Include opt files in the kernel with "" instead of <>.
Mon, Jul 10, 5:08 AM
imp committed rS320858: Better contain MMCCAM parts of this file.
Better contain MMCCAM parts of this file
Mon, Jul 10, 3:38 AM
imp committed rS320856: Add dependency on opt_cam.h and opt_mmccam.h.
Add dependency on opt_cam.h and opt_mmccam.h
Mon, Jul 10, 3:38 AM
imp committed rS320857: Opt files are included with single quotes..
Opt files are included with single quotes.
Mon, Jul 10, 3:38 AM

Sun, Jul 9

imp committed rS320850: Back out enabling the card interrupt detection bit. It is not ready to.
Back out enabling the card interrupt detection bit. It is not ready to
Sun, Jul 9, 8:49 PM
imp committed rS320849: Reconnect mmc and mmcsd disconnected unintentioanlly in mmccam commit..
Reconnect mmc and mmcsd disconnected unintentioanlly in mmccam commit.
Sun, Jul 9, 8:42 PM
imp committed rS320847: Added new tool for doing experiments with SDIO card..
Added new tool for doing experiments with SDIO card.
Sun, Jul 9, 5:06 PM
imp committed rS320846: New command 'mmcsdcmd' for camcontrol, to allow interacting with SD cards.
New command 'mmcsdcmd' for camcontrol, to allow interacting with SD cards
Sun, Jul 9, 5:03 PM
imp committed rS320845: Added mmcnull, an emulated lightweight MMC controller.
Added mmcnull, an emulated lightweight MMC controller
Sun, Jul 9, 5:03 PM
imp committed rS320844: An MMC/SD/SDIO stack using CAM.
An MMC/SD/SDIO stack using CAM
Sun, Jul 9, 4:57 PM

Fri, Jul 7

imp committed rS320788: Bump date for today's commit..
Bump date for today's commit.
Fri, Jul 7, 4:59 PM
imp committed rS320787: Improve wording for -E and -t flags. -E never writes the entire disk,.
Improve wording for -E and -t flags. -E never writes the entire disk,
Fri, Jul 7, 4:54 PM
imp added a comment to D11433: Add Format NVM support to nvmecontrol.

While complete, this interface is a total PITA. End to end protection type 2 is what again? Oh, I have to go look in the standard to understand all these parameters?
Can we at least have a description of what's going on here? A table for each of the magic numbers?

Fri, Jul 7, 4:12 PM

Sun, Jul 2

imp added a comment to D11432: sbin/nvmecontrol: fix build.

This was fixed at r320522

Sun, Jul 2, 5:41 PM

Sat, Jul 1

imp added a comment to D11433: Add Format NVM support to nvmecontrol.

Is this really format, or is it namespace provisioning? There's another set of name space provisioning patches that are also under review right now.

Sat, Jul 1, 7:30 PM
imp added inline comments to D11432: sbin/nvmecontrol: fix build.
Sat, Jul 1, 7:28 PM
imp committed rS320522: Fix sign of resid and add a mostly useless cast to cope with signed vs.
Fix sign of resid and add a mostly useless cast to cope with signed vs
Sat, Jul 1, 2:19 AM
imp added inline comments to D11432: sbin/nvmecontrol: fix build.
Sat, Jul 1, 2:13 AM

Thu, Jun 29

imp committed rS320483: Improve wdc error log pulling..
Improve wdc error log pulling.
Thu, Jun 29, 11:15 PM

Tue, Jun 27

imp committed rS320425: Report some aspects of namespaces and namespace support in identify.
Report some aspects of namespaces and namespace support in identify
Tue, Jun 27, 8:25 PM
imp committed rS320424: Add new definitions for namespaces..
Add new definitions for namespaces.
Tue, Jun 27, 8:24 PM
imp committed rS320423: Move 128-bit integer routines to util.c so they can be used by more.
Move 128-bit integer routines to util.c so they can be used by more
Tue, Jun 27, 8:24 PM
imp committed rS320412: Namespace is 32-bits, don't cast it to 16 here.
Namespace is 32-bits, don't cast it to 16 here
Tue, Jun 27, 4:48 PM

Mon, Jun 26

imp committed rS320389: Sort the compat11.* syscalls I added. Remove duplicate compat11.stat..
Sort the compat11.* syscalls I added. Remove duplicate compat11.stat.
Mon, Jun 26, 10:48 PM

Jun 25 2017

imp added a comment to D10247: Add CAM passthrough for NVMe.

This looks good to me as well...

Jun 25 2017, 7:08 PM

Jun 24 2017

imp added a comment to D11344: Clean up stale dependencies after r320278.

While not technically incorrect (except maybe the lib32 comment), this papers over a weakness in the new lazy depend generation that should actually be fixed in said generation. Or failing that, the check belongs in libc generically so we don't have to maintain these silly lists.

Jun 24 2017, 6:14 PM
imp committed rS320310: Document that the dependencies aren't quite right for non-clean build..
Document that the dependencies aren't quite right for non-clean build.
Jun 24 2017, 2:33 PM
imp committed rS320302: Be sure to free allocated statfs11 buffer..
Be sure to free allocated statfs11 buffer.
Jun 24 2017, 12:28 AM

Jun 23 2017

imp committed rS320279: Decode FreeBSD 11 compat stat, fstat and lstat calls..
Decode FreeBSD 11 compat stat, fstat and lstat calls.
Jun 23 2017, 6:07 PM
imp committed rS320278: Forward compatibility for ino64..
Forward compatibility for ino64.
Jun 23 2017, 6:06 PM
imp closed D11185: Forward compatibility for ino64. by committing rS320278: Forward compatibility for ino64..
Jun 23 2017, 6:06 PM

Jun 20 2017

imp added a comment to D11185: Forward compatibility for ino64..
In D11185#233556, @imp wrote:

Rebase to latest tip of the spear...

Jun 20 2017, 6:55 PM
imp updated the diff for D11185: Forward compatibility for ino64..

Rebase to latest tip of the spear...

Jun 20 2017, 6:47 PM
imp updated the diff for D11185: Forward compatibility for ino64..

Remove unused includes, per kib.

Jun 20 2017, 6:23 PM
imp added inline comments to D11185: Forward compatibility for ino64..
Jun 20 2017, 6:17 PM
imp added a comment to D11185: Forward compatibility for ino64..

I've updated the summary to be the commit message, modulo the content we put in the commit message that differential barfs on.

Jun 20 2017, 4:59 PM
imp updated the summary of D11185: Forward compatibility for ino64..
Jun 20 2017, 4:58 PM
imp updated the summary of D11185: Forward compatibility for ino64..
Jun 20 2017, 4:57 PM
imp updated the diff for D11185: Forward compatibility for ino64..

Latest nits from kib@

Jun 20 2017, 4:54 PM
imp added a comment to D11185: Forward compatibility for ino64..

I consider this compat work as optional and done by will of the submitter, not as a precedent enforcing new project policy on forward-incompatible ABI changes.

In my opinion I think we should neither mandate nor discourage forward-compatibility shims.

Jun 20 2017, 4:39 PM
imp updated the diff for D11185: Forward compatibility for ino64..

Add getfsstat. needed for df.

Jun 20 2017, 4:55 AM

Jun 19 2017

imp added a comment to D11185: Forward compatibility for ino64..

OK, with the latest update, I think I've addressed everything there.

Jun 19 2017, 5:49 PM
imp updated the diff for D11185: Forward compatibility for ino64..

Fix leak I overlooked.

Jun 19 2017, 5:49 PM
imp updated the diff for D11185: Forward compatibility for ino64..

Missed a spelling mistake kib@ found.

Jun 19 2017, 5:42 PM
imp updated the diff for D11185: Forward compatibility for ino64..

Implement kib's suggestions (hopefully I didn't miss any)

Jun 19 2017, 5:40 PM

Jun 18 2017

imp committed rS320083: Put ARM_USE_V6_BUSDMA into the SAM9G20EK reference kernel to try to.
Put ARM_USE_V6_BUSDMA into the SAM9G20EK reference kernel to try to
Jun 18 2017, 9:04 PM
imp committed rS320081: Include the generic cpu.h instead of the v4/v6 specific cpu.h. This.
Include the generic cpu.h instead of the v4/v6 specific cpu.h. This
Jun 18 2017, 9:04 PM
imp committed rS320082: Create a new option ARM_USE_V6_BUSDMA to force an armv4/5 kernel to.
Create a new option ARM_USE_V6_BUSDMA to force an armv4/5 kernel to
Jun 18 2017, 9:04 PM
imp committed rS320080: Load the transmit dma buffer at attach time as well. We don't need to.
Load the transmit dma buffer at attach time as well. We don't need to
Jun 18 2017, 9:03 PM

Jun 15 2017

imp updated the diff for D11185: Forward compatibility for ino64..

Updated with the various issues raised in the code review: weak
symbols, osreldate, missing fields.

Jun 15 2017, 3:04 PM

Jun 14 2017

imp added inline comments to D11185: Forward compatibility for ino64..
Jun 14 2017, 2:51 PM

Jun 13 2017

imp updated the diff for D11185: Forward compatibility for ino64..

again

Jun 13 2017, 9:21 PM
imp updated the diff for D11185: Forward compatibility for ino64..

Trying with magic in git.config file.

Jun 13 2017, 9:21 PM
imp updated the summary of D11185: Forward compatibility for ino64..
Jun 13 2017, 9:02 PM
imp created D11185: Forward compatibility for ino64..
Jun 13 2017, 9:01 PM

Jun 9 2017

imp added a comment to D11115: Clang groks .codeNN; remove CLANG_NO_IAS from sys/boot/i386.
In D11115#230152, @dim wrote:

I think this is a good idea, but the last time I tried this...

Yes important point - now I seem to recall we spoke about this in the past and you pointed this out but I can't find details. Perhaps it was on IRC. I have been running a similar patch in test trees for quite some time, but will do a more detailed comparison of the differences.

Jun 9 2017, 8:17 PM

Jun 2 2017

imp accepted D11014: msdosfs: use mem{cpy,move,set} instead of bcopy,bzero.

There's no problem with either memcpy or memmove in the kernel. They just work. For like at least decade....

Jun 2 2017, 6:07 PM

May 27 2017

imp added inline comments to D10931: boot1 generate-fat: generate all templates at once.
May 27 2017, 6:06 PM
imp added inline comments to D10931: boot1 generate-fat: generate all templates at once.
May 27 2017, 5:59 PM
imp added a comment to D10948: Allow to both the forth and raw command line in the loader.

I'm not entirely sure that switching interpreters is a good idea. I rather think it's a terrible idea, but am open to seeing how it progresses before rendering final judgement.

May 27 2017, 4:40 PM
imp added inline comments to D10948: Allow to both the forth and raw command line in the loader.
May 27 2017, 4:37 PM
imp added a comment to D10642: Fix serial line terminal size..

This is starting to sound like a terminal emulation type vs term= miss match perhaps? My term size was quiet correct, that is what a standard Putty serial terminal size comes up as.

May 27 2017, 4:33 PM
imp added inline comments to D10931: boot1 generate-fat: generate all templates at once.
May 27 2017, 12:03 AM

May 26 2017

imp added a comment to D10489: Add EXAMPLES section to uname(1).

OK, let's see if I understood you correctly this time Warner. make(1) is indeed apparently setting MACHINE and MACHINE_ARCH globally.

May 26 2017, 11:35 PM · manpages

May 25 2017

imp added a comment to D10642: Fix serial line terminal size..

Isnt this caused by a missing entry in /etc/ttys for the serial console? This should be coming from there, not from .dot files.

May 25 2017, 1:51 AM

May 22 2017

imp accepted D10764: sys/: Remove glimpse make target added in r181432.

I don't know if there's folks still using glimpse from before... But it's been long enough that I think it can go.

May 22 2017, 2:57 PM

May 20 2017

imp added a comment to D10787: Expose the ILP32/LP64 programming environments based on __ILP32__/__LP64__ instead of by architecture..
In D10787#224240, @ngie wrote:
In D10787#223634, @imp wrote:
In D10787#223484, @ngie wrote:

Only arm64 exposes __ILP32__ and __LP64__ (depending on whether or not it's 32-bit or 64-bit), per a quick grep of contrib/gcc and contrib/llvm .

All the architectures do. We use it elsewhere in the tree and it works. Your grep has lead you astray.

contrib/gcc/config/i386/freebsd64.h: builtin_define ("LP64"); \
contrib/gcc/config/rs6000/freebsd.h: builtin_define ("LP64"); \
contrib/gcc/config/sparc/freebsd.h: builtin_define ("LP64"); \

are just three examples.

I meant to say "only arm64 exposes it, in addition to the other architectures currently handled".

What I'm wondering about thought is why aren't arm and mips in this list at all? And why does powerpc assume 32 bit?

Beats me why arm/mips were never considered, but there is an issue potentially with how __ILP32__, __LP32__, and __LP64__ are defined on those architectures.

This review specifically addresses the hardcoded have_<FOO> for LP64 and ILP32 that was incorrect (maybe not when this was first written, but wasn't correct after additional architectures were added).

May 20 2017, 12:12 AM

May 18 2017

imp added a comment to D10787: Expose the ILP32/LP64 programming environments based on __ILP32__/__LP64__ instead of by architecture..
In D10787#223484, @ngie wrote:

Only arm64 exposes __ILP32__ and __LP64__ (depending on whether or not it's 32-bit or 64-bit), per a quick grep of contrib/gcc and contrib/llvm .

May 18 2017, 3:12 PM
imp requested changes to D10787: Expose the ILP32/LP64 programming environments based on __ILP32__/__LP64__ instead of by architecture..

Actually I think I take that back... mips and arm aren't listed at all. Are they affected?

May 18 2017, 6:57 AM
imp accepted D10787: Expose the ILP32/LP64 programming environments based on __ILP32__/__LP64__ instead of by architecture..
May 18 2017, 6:55 AM

May 17 2017

imp accepted D10537: Make sure <arch-gcc> come with consistent content.

Looks good to my eye as well...

May 17 2017, 6:03 PM
imp accepted D10642: Fix serial line terminal size..

Looks good to me.

May 17 2017, 12:08 AM

May 16 2017

imp added a comment to D10489: Add EXAMPLES section to uname(1).

Strictly speaking, you are correct, but man pages often have references elsewhere, and having it here wouldn't be terrible.

Understood, fair enough. Would .Xr build 7 reference suffice (it already establishes a connection between variables and uname -[mp] output there), or you'd rather duplicate this information explicitly here as well?

May 16 2017, 3:53 PM · manpages