In D11730#244159, @imp wrote:

In D11730#243975, @rpokala wrote:

I recall @imp specifically advising me that any access to the device should be done in attach, not in probe.

Fascinating. For my education, could you explain why, @imp?

Because writing to the IIC bus can cause a write cycle to EEROMs.

make tinderbox JFLAG=-j16 TARGETS="mips powerpc sparc64" UNIVERSE_TARGET=buildworld

I confirmed that this mips.mips.buildworld works; the other MIPS builds, PowerPC, and Sparc64 are in progress.

In D11771#243977, @sevan wrote:

In D11771#243963, @rpokala wrote:

That seems like and important limitation, so yeah, I'd include that info.

Sure, add a BUGS section?

I recall @imp specifically advising me that any access to the device should be done in attach, not in probe.

Also: is that the right URL? The snippet doesn't appear there.

Not sure if I should extend the man page to state that hot plug isn't supported on FreeBSD (like on OS X) hence device should be connected prior to system power up and removal should be avoided when system is live (system stays up if I recall correctly, but kernel freaks out that a bge interface just disappeared).

In D11730#243574, @avg wrote:

One thing that can be considered a regression in the proposed code is that now device_set_desc() is called from the attach method, not from the probe method as before.
That's fine in general, but the messages printed just before DEVICE_ATTACH do not contain any description now.

Can you point to a copy (or even a recent draft?) of the TSE2004av spec for reference?

@zbb committed this independently as r320001.

Thanks for the review, and sorry about the breakage!

The rest of ether_ifattach() foregoes braces for single-line blocks, so
do the same.

It would also be good if the example wasn't using an architecture that's planned to be de-orbited "soon".

@glebius - Please review at your earliest convenience. If you don't think you can get to it in the next week, I'll find someone else. Thanks!

Address review comments from brooks: only store / retrieve for IFT_ETHER.

LGTM, but @imp should have the final say.

In D10489#217460, @imp wrote:

In D10489#217456, @rpokala wrote:

If "platform" (-m) and "processor architecture" (-p) are the same as the TARGET and TARGET_ARCH, then it would be great to include that too.

They are MACHINE and MACHINE_ARCH which are universal, please document them as such. The build man page already gives the translation for the TARGET and TARGET_ARCH which only have meaning in Makefile.inc1 (eg, the top level of buildworld where they are used to set MACHINE and MACHINE_ARCH).

If "platform" (-m) and "processor architecture" (-p) are the same as the TARGET and TARGET_ARCH, then it would be great to include that too.

Please regenerate the diffs w/ proper context. See https://wiki.freebsd.org/action/show/Phabricator for details on how to do that.

Actually, forget this -- I'll actually implement "cat". Fortunately, it's in C, not FICL, so I have a chance. :-)

Update the date.

Hi Allan, this patch has been sitting idle for a few months, could you either commit it or abandon it?

Fair enough. :-)

It seems to me the two ReadBlocks() calls could be consolidated, which would allow you to also include the buffer size in the DPRINTF(). Something like this:

Warner and Warren are both right - this functionality would fit in well in either g_sched, or as part of g_nop.

Ah, I remembered the context! bdes was involved in decrypting the video of one of Kirk's lecture series.

Is it useless? ISTR using bdes in the not-too-distant past...

Is there any particular reason not to just put them in the build output directory?

Thanks. I'm tinderboxing right now, will submit when that's done.

Note that @bmueller_panasas.com is the originator of this patch, so I happily defer to his explanation.

@rwatson - the most recent commit that mentions m_pulldown() was yours (r276884); could you either review this in the near future, or else suggest someone else? Thanks!

Ah, you already submitted. Well then, please consider these comments as enhancement requests, and/or ignore them. :-)

Similar updates for cxgbev.4 as for cxgbe.4.

@imp approved this on IRC last night:

'temp' is the buffer you read the header into, and also what you use to write the "cleared" header. So what's 'buf'?

Make sure to s/inquiery/inquiry/ for the description before submitting. :-)