sheabunge
commented
11 years ago This could be an issue with line endings.
Closed tcwan closed 11 years ago
sheabunge
commented
11 years ago This could be an issue with line endings.
botbench
commented
11 years ago I am not familiar with git, but could this be the issue? https://coderwall.com/p/mgi8ja
tcwan
commented
11 years ago @botbench: Ouch. I don't think I'd want to go the way of case-sensitive OS X file system.
I suspect that the problem is more complex than just line endings or case sensitivity. I tried tweaking the case sensitive switch in .git/config, it does nothing.
Then I thought it was a git on Mac OS X regex problem with the .gitignore entries, but removing the '!extra/linux-devkit//.d' entry does not help. Git List
This is a snippet of the output of git diff; it appears to think that there has been a change between the latest version and some earlier version (?) of the file.
$ git diff|more
diff --git a/extra/linux-03.20.00.13/Documentation/IO-mapping.txt b/extra/linux-03.20.00.13/Documentation/IO-mapping.txt
index 1b5aa10..473e43b 100644
--- a/extra/linux-03.20.00.13/Documentation/IO-mapping.txt
+++ b/extra/linux-03.20.00.13/Documentation/IO-mapping.txt
@@ -1,208 +1,82 @@
-[ NOTE: The virt_to_bus() and bus_to_virt() functions have been
- superseded by the functionality provided by the PCI DMA interface
- (see Documentation/PCI/PCI-DMA-mapping.txt). They continue
- to be documented below for historical purposes, but new code
- must not use them. --davidm 00/12/12 ]
+The io_mapping functions in linux/io-mapping.h provide an abstraction for
+efficiently mapping small regions of an I/O device to the CPU. The initial
+usage is to support the large graphics aperture on 32-bit processors where
+ioremap_wc cannot be used to statically map the entire aperture to the CPU
+as it would consume too much of the kernel address space.
-[ This is a mail message in response to a query on IO mapping, thus the
- strange format for a "document" ]
+A mapping object is created during driver initialization using
-The AHA-1542 is a bus-master device, and your patch makes the driver give the
-controller the physical address of the buffers, which is correct on x86
-(because all bus master devices see the physical memory mappings directly).
+ struct io_mapping *io_mapping_create_wc(unsigned long base,
+ unsigned long size)
-However, on many setups, there are actually _three_ different ways of looking
-at memory addresses, and in this case we actually want the third, the
-so-called "bus address".
+ 'base' is the bus address of the region to be made
+ mappable, while 'size' indicates how large a mapping region to
+ enable. Both are in bytes.
-Essentially, the three ways of addressing memory are (this is "real memory",
-that is, normal RAM--see later about other details):
+ This _wc variant provides a mapping which may only be used
+ with the io_mapping_map_atomic_wc or io_mapping_map_wc.
- - CPU untranslated. This is the "physical" address. Physical address
- 0 is what the CPU sees when it drives zeroes on the memory bus.
+With this mapping object, individual pages can be mapped either atomically
+or not, depending on the necessary scheduling environment. Of course, atomic
+maps are more efficient:
- - CPU translated address. This is the "virtual" address, and is
- completely internal to the CPU itself with the CPU doing the appropriate
- translations into "CPU untranslated".
+ void *io_mapping_map_atomic_wc(struct io_mapping *mapping,
+ unsigned long offset)I have a CentOS 6.4 machine, guess I'll have to make to with that for now. The ev3sources repository works fine on that system (git 1.7.x).
tcwan
commented
11 years ago EDIT: Removed list of files with multiple-casing since most of them are from the original Linux source tree and should not be changed.
See: https://groups.google.com/forum/#!topic/git-users/FwG2UefGmeo http://stackoverflow.com/questions/7383426/cloning-a-git-repo-and-it-already-has-a-dirty-working-directory-whaaaaa
I found the source of the problem: e.g., for ~/ev3sources/extra/linux-03.20.00.13/Documentation/IO-mapping.txt
On Linux, There are two separate files in the directory:
$ ll io-mapping.txt IO-mapping.txt
-rw-rw-r--. 1 ev3builder ev3builder 3288 Aug 5 12:14 io-mapping.txt
-rw-rw-r--. 1 ev3builder ev3builder 8049 Aug 5 12:14 IO-mapping.txtMac OS X is case insensitive, so only one file with different casing can exist. On Mac OS X:
$ ll io-mapping.txt IO-Mapping.txt
-rw-r--r-- 1 tcmac staff 3288 Aug 28 10:57 IO-Mapping.txt
-rw-r--r-- 1 tcmac staff 3288 Aug 28 10:57 io-mapping.txtTechnically there's only one file, but Mac OS X ls -l permitted the display of the io-mapping file as capitalized IO-Mapping.txt, which is confusing... but tab-completion only found one actual file, which is io-mapping.txt. (IO-Mapping.txt was overwritten during git clone).
Unfortunately Linux uses such multiple-casing files in the source tree, and there does not appear to be a clean way to support checkout out the git repository to a case-insensitive file system such as HFS+ default configuration on the Mac OS X. When checking out the Linux source tree on Mac OS X, one of the files would be overwritten, making it appear to have been modified.
There are two files/folder in the LEGO Firmware subdirectory which have this problem:
lms2012/lms2012/doc/html/PWMModule.html vs. lms2012/lms2012/doc/html/PwmModule.html
lms2012/lmssrc/TEST vs. lms2012/lmssrc/TestIs the PWMModule.html file generated? It appears that PwmModule.html is an earlier version than PWMModule.html and can be removed.
The only way to solve the TEST vs. Test name conflict problem is to rename one of them.
tcwan
commented
11 years ago I wonder if it would be possible to work on the LEGO FIrmware (lms2012) on Mac OS X without encountering this problem as long as I don't access the Linux source tree. This would mean splitting the repository into the Linux source portion and the LMS portion as separate repositories, and fixing the two file/directory name conflicts mentioned in the previous comment.
This assumes that the lms firmware source does not include any kernel modules that need to be build along with it and that it access any kernel services via the C library only.
botbench
commented
11 years ago Fixed in the latest commit. Test and TEST are completely different folders which cannot simply be renamed
tcwan
commented
11 years ago Hi Xander,
Commit 3fe985d33b8e9ef6550b2c3db016e06b26bc9468 should probably be reverted. It is not just one doc file that is affected in the Linux tree. I only used that as an example of the problems related to case-insensitivity in HFS+. There are several in the net modules which cannot be fixed so easily as the author used uppercase and lowercase filenames to mean something different, and changing those filenames will probably break many things (since they affect include filenames).
botbench
commented
11 years ago I am not sure this patch has to be reverted though. It may not fix the other things, but it fixes one and that's still more than none :)
tcwan
commented
11 years ago Ok. Well, that is fine if you plan to update the linux kernel repository only rarely (i.e., complete kernel source tree update/refresh instead of file by file).
I did a fresh checkout of the ev3sources repository to my Mac, and am puzzled by the state of the repository:
$ git --version git version 1.8.3.4
If I try to
git checkout -- extra/linux-03.20.00.13/Documentation/IO-mapping.txt, for example, it will leave a lowercase io-mapping.txt file in the modified state, which I cannot seem to remove.