[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: status grub2 port of grub-legasy map command

From: John Stanley
Subject: Re: status grub2 port of grub-legasy map command
Date: Fri, 17 Apr 2009 20:01:38 -0400
User-agent: Thunderbird (X11/20090302)

Ok, that sounds good... I feel better about it then. I didn't mean directly modifying bios data, but through doc'd bios ints of course. It been a long, long time since I've looked at (or dealt with) bios code, so I was was simply wondering if boot device naming could be modified in a documented way nowadays-- after all, the functionality has been available in the bios setup in pcs for at least 10 years or so.

Vladimir Serbinenko wrote:

On Sat, Apr 18, 2009 at 1:12 AM, John Stanley <address@hidden <mailto:address@hidden>> wrote:

    Hi Javier and all,
    I could probably have a version of the drivemap completed this
    weekend as well, but since I've basically simply adapted your
    drivempa.patch.8 to r2106, with little change, I'd be more
    comfortable going with your new patch since you know the code much

    In addition, in the last several days,  have started leaning away
    from it altogether -- because of the use  of an int13 intercept
    TSR. When I started looking at the drivemap patch about a week
    ago, I assumed it simply did some sort of bios (internal) table
    swapping only. I'm not really comfort able with the int13 handler
    redirect. I worry about (possibly rare) problems downstream while
    running Windows. On the other hand, I know it "does work," as I
    and many others have been using map with grub-legasy for several
    years now. Nevertheless, I'm now a bit apprehensive.

Modifying internal bios tables isn't practicable because they may be anywhere and in any format. Windows follows the memory map supplied by int12/int15/bda which says that the ranges used by hook are unusable. Also even if windows overwrites int13 handle it doesn't matter at all because windows switches to its own disk drivers after initial start

    For me, for the time-being, as my laptops are all Thinkpads, which
    have bios supplied "boot device table"  functionality (via f12 on
    poweron), I can live without drivemap for those occasions when I
    need to come down from the hilltop to work on Windows.

    What I'd like to do with drivemap, is to do boot device swapping
    by changing in the bios which device is to be treated as the
    "first" boot device, which is the second, etc. I know this is
    doable in principle, but it may not be practical, or wise-- I'm
not sure. There is no public API to do so. So you need to reverse engineer BIOS which is impractical to do for every possible mobo.

     It would also have to be done in a way which does not "pull the
    rug out on grub" insofar as boot device enumeration is concerned.

    Javier Martín wrote:

        Hello there. I am the original author of the drivemap command.
        I was
        told by a friend that it was being discussed again on the GRUB
        list, so
        I came back and examined the two new enabling functionalities,
        hooks and mmap. I've adapted drivemap to use them both, and I'm
        polishing some rough edges. I might send a new version of the
        patch this
        weekend. Should people, however, prefer John's version, I'd be
        glad to

        El mié, 15-04-2009 a las 11:34 +0200, phcoder escribió:
            Yes it is. Also it's better to use grub_mmap_iterate
            instead of basing the location on 0x413 value. How to do
            it look at mmap/i386/pc/mmap.c
        The preboot hooks patch works beautifully. However, mmap
        causes some
        sort of glitch that makes FreeDOS (one of my three drivemap tests,
        together with ReactOS and XP) triple-fault. I've been trying
        to debug it
        with GDB-over-QEMU, but it is a real PITA. I haven't found any
        sort of
        bug in the mmap code, so I'm quite dumbfounded right now.
        I'm proceeding to the XP test, which would likely be the most
        common use
        case for drivemap.


        Grub-devel mailing list
        address@hidden <mailto:address@hidden>

    Grub-devel mailing list
    address@hidden <mailto:address@hidden>


Grub-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]