- User Since
- Jun 2 2014, 4:20 PM (280 w, 4 h)
Generally I like this. I'm unsure of DEV_ACPI stuff is proper...
I didn't see you address Brooks' objection in the posted thread. given the extreme level of exposure here, it needs to be answered satisfactorily
Where was this discussed?
Sat, Oct 12
lgtm.. do you have someone to commit this yet?
Fri, Oct 11
Thu, Oct 10
This seems sane to me...
I'd e tempted to split this into two commits. One for geom_ctl and one for g_nop.
Wed, Oct 9
You either want to return success synchronously, or return failure and not change things... so long as there are those semantics, a timeout is fine.
The newbus side of this looks good
Looking giant around bus scan is, sadly, still required. Yea asserts I added :)
Tue, Oct 8
Looking at Brooks' ask for llvm90, I think it's not quite ready for prime time, as we fail early in the build:
% make buildworld CROSS_TOOLCHAIN=llvm90 TARGET_ARCH=mips64 ... --- libstdc++.so.6.full --- building shared library libstdc++.so.6 /usr/local/bin/clang90 -target mips64-unknown-freebsd13.0 --sysroot=/usr/home/imp/obj/usr/home/imp/git/head/mips.mips64/tmp -B/var/empty -EB -mabi=64 -Wl,--version-script=libstdc++.map -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel -o libstdc++.so.6.full -Wl,-soname,libstdc++.so.6 `NM='nm' NMFLAGS='' lorder bitmap_allocator.pico pool_allocator.pico mt_allocator.pico codecvt.pico compatibility.pico complex_io.pico ctype.pico debug.pico debug_list.pico functexcept.pico globals_io.pico ios.pico ios_failure.pico ios_init.pico ios_locale.pico limits.pico list.pico locale.pico locale_init.pico locale_facets.pico localename.pico stdexcept.pico strstream.pico tree.pico allocator-inst.pico concept-inst.pico fstream-inst.pico ext-inst.pico ios-inst.pico iostream-inst.pico istream-inst.pico istream.pico locale-inst.pico misc-inst.pico ostream-inst.pico sstream-inst.pico streambuf-inst.pico streambuf.pico string-inst.pico valarray-inst.pico wlocale-inst.pico wstring-inst.pico atomicity.pico codecvt_members.pico collate_members.pico ctype_members.pico messages_members.pico monetary_members.pico numeric_members.pico time_members.pico basic_file_stdio.pico c_locale.pico atomicity.pico codecvt_members.pico collate_members.pico ctype_members.pico messages_members.pico monetary_members.pico numeric_members.pico time_members.pico basic_file_stdio.pico c_locale.pico stubs.pico del_op.pico del_opnt.pico del_opv.pico del_opvnt.pico eh_alloc.pico eh_arm.pico eh_aux_runtime.pico eh_call.pico eh_catch.pico eh_exception.pico eh_globals.pico eh_personality.pico eh_term_handler.pico eh_terminate.pico eh_throw.pico eh_type.pico eh_unex_handler.pico guard.pico new_handler.pico new_op.pico new_opnt.pico new_opv.pico new_opvnt.pico pure.pico tinfo.pico tinfo2.pico vec.pico vterminate.pico cp-demangle.pico | tsort -q` -Wl,-f,libsupc++.so.1 -lm ld: error: can't create dynamic relocation R_MIPS_64 against local symbol in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output
so I'm going to remain open to making that possible in the future, but won't gate this review on making that work (unless I find a way to make it go).
I'll note it would be nice to have a more generic xtoolchain thing for things like llvm and/or "I'd like to do a universe with all the external toolchains regardless of base compiler support"
xtoolchain part of the IRC ask
On IRC, it was suggested I do the right thing for mips, etc if llvm90 and/or mips-gcc is installed. Will noodle around on that and post an update with riscv moved.
Mon, Oct 7
So with the suggested changes, I'm not able to get very far with the patches in this review. With wulf's code I'm able to get the device probed. With this code, I see the following:
Fri, Oct 4
I'm cool with jhb's reasoning, so this looks ready to land.
I think this is OK. But since it's only /dev that's being mounted here, is the reported problem with aio on raw devices?
Thu, Oct 3
Unit numbers are kinda lame. Wouldn't it be better to add aliases?
Wed, Oct 2
querying for hptFOO: no controller returns the same number of hits. Spot checking again shows no actual indicated use.
Tue, Oct 1
This has been comitte.d
I thought I'd committed this stuff already...
Mon, Sep 30
I've had no requests in the last 4 years since I posted this...
Sun, Sep 29
Sat, Sep 28
Fri, Sep 27
Thu, Sep 26
This looks good to me. I'll update the port with it shortly.
Wed, Sep 25
I had very similar code in FORTH for our boot loader and it didn't work with EFI, just comconsole. while we've transitioned to teken, it looks like it eats the ESC c and does a reset for the eficonsole, which means that efi's com redirect in the BIOS doesn't work.
Does this work for EFI console? When I tried it, the terminal emualtor intercepted the escape sequences and so the serial console didn't get them...
Do we need this now that tsoome has committed all his stuff to fix the broken color stuff that lead to this situation in the first place?
This looks good to my eye. Don't know if it will work...
This looks good to me.
At least according to https://techpubs.jurassic.nl/manuals/0530/developer/Cplr_PTG/sgi_html/apa.html which appears to be the reproduction of the sgi assembler manual from whence all this stuff came.
How do you know offset 12 on the stack is a good place to store this? I'd expect there to be something like:
cprestore will store gp to <offset>(sp) and then load it from there after every jal operation to restore gp.
Tue, Sep 24
I'm struggling to understand here. How does this make it a real option? It seems to say that you must include iflib to get these drivers and there will be no warning if you don't. Maybe I'm misunderstanding something here, but that strikes me as unwise on its surface. I don't think this is a good idea at all, unless I'm missing something.
I'm currently in transit from EuroBSDcon and will likely be out of commission for a couple of days. I'd like to request the favor of getting a chance to review this once I've recovered before you push it in. Thanks!
Sat, Sep 21
Seems fine to me. Does this cause an issue for other users of LinuxKPI?
I was going to suggest adding the devmatch changes, but no other ACPI driver seems to have them yet, so I can do that in a sweep.
Fri, Sep 20
This looks good to me.
Mon, Sep 16
So I think this belongs in share/mk/src.sys.env.mk, but I'm not sure.
Sep 14 2019
If you need more than one sync, then you've broken posix semantics.
Sep 12 2019
Modulo kib's quibble, this is ready to go. No need to repost the review if all you change is the .Dd date and kib's thing.
I wonder why we still have fmtree though
Sep 11 2019
I fear this is the last bad choice we have.