I agree this is good today.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 21 2019
Feb 20 2019
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.
Feb 19 2019
looks good to me.
Feb 18 2019
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.
Feb 16 2019
Feb 15 2019
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.
Feb 14 2019
Since this appears to come from a non-committer, and it's trivial, I'll just commit it.
Feb 13 2019
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.
Feb 12 2019
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?
Feb 10 2019
I wonder: why not leverage tsort?
Feb 9 2019
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.
Feb 7 2019
Feb 5 2019
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.
Feb 4 2019
Jan 31 2019
Jan 30 2019
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
Jan 29 2019
Jan 28 2019
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.
Jan 24 2019
Jan 18 2019
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.
Jan 12 2019
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.
Jan 11 2019
Jan 10 2019
how is this different than uefisign(8)?
Jan 9 2019
Jan 8 2019
This looks reasonable to me.
Jan 7 2019
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.
Jan 4 2019
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.
Jan 3 2019
This looks generally good to me, but I've not taken the time to verify every bit is correctly serialized / deserialized.
Jan 2 2019
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...
Dec 31 2018
Dec 30 2018
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.
Dec 24 2018
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.