I love this. Or at least the idea of this.
If we also kill some of the type-punning that remains for disk_devdesc and other types, I think we'll have tamed the beast
I've not checked through every single instance as I'm busy today, but wanted to blast out that I loved this.
The only other alternative might be to have a flags field inside of disc_devdesc which controls this sort of behavior if that would be easier. Given how pervasive this idiom is, though, I'm guessing maybe not. I mention this in case I'm wrong in my guess.

looks good to me.

Can we please spell -1 "SLICE_ONLY" or "Full slice" or something similar? I hate -1 being a special case that I have to puzzle out for each instance of it we have in the code.

Go ahead and commit. This won't collide with anything I have out of the tree at the moment, and it's better to have better messages in the mean time.

In D19203#410890, @jhb wrote:

I haven't needed this when building mips64 on clang 6. clang 7 can't build mips due to a different regression (but not in this file).

This code looks good to me. I take no positions on any name stuff. The one thing I saw is not relevant to this change, so forgive my side comment.

This cleans up one of the abuses of the devdesc stuff. Thank you.

Since this appears to come from a non-committer, and it's trivial, I'll just commit it.

OK. I'm happy with the due diligence that's been done, and look forward to better timeout handling.
In general, our error recovery from timeout sucks, so I wouldn't be too hard on the vendor.

In D19168#410022, @dab wrote:

I can test on hardware at $WORK. As to it being vendor code, although the driver was imported from PMC-Sierra 3 years ago, it doesn't look to me like any updates have come from them since. If you know of a source of updated vendor code, can you point me to it?

I ask because it's basically vendor code.

do you have the ability to test this change?

I wonder: why not leverage tsort?

Would it make sense to add araujo's name to the usr.sbin/byhve line?

I thought we did this years ago...
Now is a great time to do it. If there are issues, we'll find out in plenty of time to either (a) fix or (b) chicken out.

Hmm, looking at the dates, this pre-dates the lua integration and is likely OBE.

I worked really hard so we wouldn't have to do this. Do not commit this.
What problem is being solved here?
The original LUA loader submission had stuff like this in it, and I specifically rejected it and made all the files that lua needed usable / mimicked in libstand by linking those files to stand.h and having stand.h define everything that's needed.

In D19012#406701, @0mp wrote:

In D19012#406455, @crees wrote:

I think it should be NRTbdehnotqx, shouldn't it? I'm sure most of our manpages are like that.

It depends. ls(1) has -ABab while grep(1) has -AaBb. Personally, I prefer -AaBb. It's also what the example for the Fl macro suggests in mdoc(7):

.Op Fl 1AaCcdFfgHhikLlmnopqRrSsTtux

Dashes in labels won't cause problems for geom or the boot loader, so I think this is a good change. Thanks for driving it.

I just made a pass through for anything that caught my eye, and found a couple. I have not reviewed it to see if it matches the hardware spec for what it's trying to control.

This is fine, but there's a chance we'll rework the arg parsing in this program in the near future... Better to get this in now though.

Lua bits look good

how is this different than uefisign(8)?

This is fine.

This looks reasonable to me.

This works for me. There is a newer way to cope with this, but I don't think the 4600 implements this, so this change is appropriate.

Just checked the LUA bits, but they are fine. My acceptance is only for that.

Most MFCs don't need phab reviews, btw. This one looks fine...

In D18742#399975, @pi wrote:

Hmm, I still use

apm

daily to check the battery status of my laptops. What would be the alternative ?

I doubt there's any FreeBSD machines running FreeBSD 6 or newer using APM today. This stopped being relevant around Pentium MMX 200MHz time frame, and was relevant only for laptops. You can safely completely and totally ignore the APM method. We should GC all that code.

10,000 is a bit arbitrary, but is a decent enough limit. 1k likely would do the trick, but maybe not always and wouldn't help the speed much at all. 100k likely would be measurably slower. I know that patch collections in monta vista linux for just the kernel ran into the thousands back in the day when I had to cope with their insanity, so maybe 10k isn't all that over-high...

Thanks for tweaking this John... I don't think it's been materially changed since I wrote it 15 years ago.

This looks generally good to me, but I've not taken the time to verify every bit is correctly serialized / deserialized.

In D18703#399317, @chuck wrote:

In D18703#399189, @araujo wrote:

LGTM! Could you please set a MFC?

Absolutely. I have one in the real commit message, but Differential didn't seem to like it in the summary.

This looks good to me as well...

This looks fine, but I'd create a sysctl that publishes this information as well. devd events are just that: one shot events that say that something has changed. when we restart devd, we don't republish everything that's gone before. This looks necessary to cope with devices that are plugged into the system. Otherwise we may have a race if devd starts, processes events, then x11 and friends start and expect this event in the queue. Maybe it is, maybe it isn't. devd is designed to have no memory, and I really really want to keep it that way.

We don't remember any old events.
You need to find a different way to get this information through the system.
I'd suggest a sysctl that publishes this information that can be read.

I think this is fine, but I'm not totally sure.

Works for me. Again, I think it was a mistake to have flags for both verbs and options, but that's what linux did and will need to be fixed in a separate commit.

I went back and forth on this when I was writing the code. I thought it was a more natural interface to say --activate #, --deactivate #, etc, rather that --activate --bootnum #. I see the use-case, though. It could be handled by a second invocation, but the original code was already confused over what set_active means (in some places using it as a boolean, other places using it and the boot number). So I think on the whole this is good, modulo my comments.

Be sure to commit these separately.