It seems that for some PCIe device driver stuff we'll want to read registers in the extended configuration space. On i386/amd64 hardware these registers can be accessed through a memory mapped register window, advertised in the ACPI MCFG table. The diff below adds support for this mechanism. Some notable points: 1. ACPI is a pile of poo. Allegedly there are machines that have an MCFG table that's full of lies. 2. Mapping the registers consumes up to 256 MB of precious KVA. To ...

A 3 line example with 3 bugs. 1. destination and destination_path should be the same. 2. source_file doesn't have to be a file. 3. mv will also unlink a directory, ala rm -d. Index: mv.1 =================================================================== RCS file: /home/tedu/cvs/src/bin/mv/mv.1,v retrieving revision 1.26 diff -u -r1.26 mv.1 --- mv.1 3 Sep 2010 09:53:20 -0000 1.26 +++ mv.1 26 Dec 2010 05:35:57 -0000 @@ -117,9 +117,9 @@ to accomplish the move. The effect is ...

this seems correct, but it was anyway. what are you trying to change here? other than that i think this diff is fine. but a technical ok would be useful too.

Hi Ted, Sure, and both should be "destination_path", because that's the term used consistently in the DESCRIPTION. Unambiguous terminology is very important here because "target" and "destination path" are not the same thing at all, but easily confused. At first, when starting to look into your bug report, Right, and indeed, it is the same as the source operand. By the way, the DESCRIPTION ought to make it plain as well Indeed, the code does contain a call to rmdir(2). However: ...

hmm... cp - copy files rm - remove directory entries mv - move files and directories # with your changes i'm ok with all approaches, but i fear we are being inconsistent on three very important utilities about how we describe things. do we accept that files and directories are the same? do we distinguish? i'd say your comma would be better placed after "directory" and not i'm not convinced. it feels like you are removing a valid warning, and turning it into an example. the ...

Hmm, I'm not too happy about moving fpuinit() out of cpu_hatch() on amd64, while leaving npxinit() in there for i386. This function will be run again upon resume. Now overwriting fpu_mxcsr_mask shouldn't hurt, but perhaps replacing: if (CPU_IS_PRIMARY(ci)) { with if (fpu_mxcsr_mask == 0) { Oh, this actually points out an interesting problem. The MXCSR register isn't initialized from data passed to us by userland. However, if a user calls ptrace(PT_SETFPREGS, ...) on a ...

On Tue, 21 Dec 2010 22:15:33 +0100 I guess these should now be one of the LOG_ names from syslog(3) so maybe something like this? Not all LOG_ levels are used in the code, as far as I can tell, but I guess that does not matter and might change in the future (so just do a man page reference rather than list the currently used levels). Index: pf.4 =================================================================== RCS file: /cvs/src/share/man/man4/pf.4,v retrieving revision 1.71 diff -u -p ...