[lkml]   [1996]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: test version of 2.1.0 available
    Wahoo!!! We are finally starting in 2.1.x!!! I can tell you about my
    experiences so far very simply... It didn't work at all. :-( I use
    loadlin to boot from an M$-DOS 6.22 boot menu (this makes my wife
    happy). I just glanced through the source for loadlin, and it _DOES_
    use hardware addresses to address kernel addresses, which means it is
    horribly broken using the new kernel. Other then rebooting instantly,
    it worked great. ;-) I suppose I will need to install lilo to get it to
    boot. I would try to hack loadlin to make it work, but I am supposed to
    turn in my thesis prospectus this week...
    Erik B. Andersen Web:
    2485 South State St. email:
    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
    > (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

     \ /
      Last update: 2005-03-22 13:38    [W:0.025 / U:14.772 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site