-- Erik B. Andersen Web: http://www.et.byu.edu/~andersee/ 2485 South State St. email: andersee@et.byu.edu Springville, Ut 84663 phone: (801) 489-1231 --This message was written using 73% post-consumer electrons--
Linus Torvalds wrote: > > Could people who are doing device drivers and other people that just want > to live dangerously check out the new pre-2.1.0.gz file that I just put > out for ftp on > > ftp://ftp.cs.helsinki.fi/pub/Software/Linux/Kernel/testing/pre-patch-2.1.0.gz > > (It's _currently_ has a md5sum of 92eb12e2275dd75fb14f6538d1a4e03d and is > 28265 bytes long, but I might be updating it). > > The new thing with the 2.1.x tree is that the kernel no longer uses the x86 > segmentation to access user mode, but instead the kernel segment covers the > whole 4GB virtual address space, and thus accesses to user memory can be made > faster. > > NOTE! When you access user memory you still have to use the "get_user()" etc > helper functions, exactly as before, because those can still do strange > things on other architectures. The new thing is just a x86 _implementation_ > issue, not a change in the basic philosophy (you'll notice that most of the > changes are to x86-specific files). > > The thing about the new memory management setup is that it gets rid of a lot > of extra fluff that isn't needed, and makes things potentially faster. > However, there is one downside to all this, and that is the fact that the > kernel address space is no longer identical to the hardware address space. > > For example, to access hardware address 0xA0000, you can no longer just do > something like this: > > value = (unsigned char *) 0xA0000; > > but instead you have to use something like this: > > value = readb(0xA0000); > > Note that I called this a "downside", but in actual fact it's a good thing. > The reason that it's a good thing is that the drivers should have been using > readb() already - that's the portable interface, and that's how you have to > access PCI shared memory on alpha and PPC machines. In fact, most drivers > have already been converted to use this interface, but there are certainly > drivers out there that will break horribly by my pre-patch. That's why I'd > like driver authors (and technical people who want to test) to try out the > pre-patch. > > Drivers that should work already (because they work on alpha's - the ones > marked with (*) have actually been tested by me on my PC with the pre-patch): > > - VGA console (*) > - IDE harddisk and CD-ROM (*) > - normal serial lines (*) > - keyboard (*) > - 3c509 network card (*) > - floppy driver (*) > - PS/2 mouse > - de4x5 and ne2000 network cards > - original ncr scsi drivers > - BSD ncr SCSI driver (at least with IO-mapped accesses) > - Aha1740, BusLogic and QLogic ISP SCSI drivers > > Other drivers are in the "may well work" category, but I cannot give any > guarantees. If some driver doesn't work, you're likely to find out sooner > rather than later (they generally break totally - it's not going to be > subtle). > > I'd love to get reports on these patches, and would be even happier if you > can also send a patch that actually fixes any broken behaviour. Things > that can break are: > - accessing device memory though a pointer > FIX: use readb/writeb/memcpy_fromio/memcpy_toio instead of trying to > dereference the pointer directly. > - using virtual addresses for controller-initiated DMA > FIX: use the "virt_to_bus()" function to change a virtual address into > a "bus" address to give to controllers that do DMA into memory. > - memory re-mapping may be broken right now, so anything that needs > "vremap()" probably doesn't work. If you have a driver that breaks due > to this, please test changing the line (line 187 in mm/vmalloc.c) > > set_pte(pte, mk_pte(offset, PAGE_KERNEL)); > > to do a > > set_pte(pte, mk_pte(offset+PAGE_OFFSET, PAGE_KERNEL)); > > and see if that helps? > > Comments? Success stories? Hate mail? Money? > > Linus