I think you should move this patch to a new thread, first because most
people in the list seem to no longer watch this one, and second because
it touches many files apart from drivemap itself. That said, I still
don't see the situation in which such an override would be used.
Oh, and I would rathe
On Mon, Jun 1, 2009 at 11:45 PM, Vladimir 'phcoder'
Serbinenko wrote:
> 2009/6/1 Javier Martín :
>> El lun, 01-06-2009 a las 11:53 +0200, Vladimir 'phcoder' Serbinenko
>> escribió:
>>> > Hmm... from those docs, and accepting that we ignore TSRs, we need to
>>> > save %ah and %dl at handler entry, t
>> I think the other
>> part of the patch should be committed right now, though.
> This might be a problem ;) (we still have no repository online:( )
Commited
--
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
ht
2009/6/1 Javier Martín :
> El lun, 01-06-2009 a las 11:53 +0200, Vladimir 'phcoder' Serbinenko
> escribió:
>> > Hmm... from those docs, and accepting that we ignore TSRs, we need to
>> > save %ah and %dl at handler entry, then check the saved %ah at exit,
>> > like the old handler from GRUB Legacy
El lun, 01-06-2009 a las 11:53 +0200, Vladimir 'phcoder' Serbinenko
escribió:
> > Hmm... from those docs, and accepting that we ignore TSRs, we need to
> > save %ah and %dl at handler entry, then check the saved %ah at exit,
> > like the old handler from GRUB Legacy did - by the way, when writing t
> Hmm... from those docs, and accepting that we ignore TSRs, we need to
> save %ah and %dl at handler entry, then check the saved %ah at exit,
> like the old handler from GRUB Legacy did - by the way, when writing the
> new handler, I asked what that code did and noone was able to tell me ¬¬
I've t
El dom, 31-05-2009 a las 21:35 +0200, Christian Franke escribió:
> Vladimir 'phcoder' Serbinenko wrote:
> >>
> >> Do not do this. Some BIOS functions (like ah=08h) return data in dl.
> >> Clients should not expect data in registers to be preserved across
> >> interrupt calls. I don't know if there
Vladimir 'phcoder' Serbinenko wrote:
Do not do this. Some BIOS functions (like ah=08h) return data in dl.
Clients should not expect data in registers to be preserved across
interrupt calls. I don't know if there is something like a 8086/PC-BIOS
ABI document that we can find to confirm the non-pr
>> AFAIR CHS FAT32 FreeDOS sector does
> No, it doesn't: check it out. It overwrites es and di quite soon indeed:
> real_start: cld
> cli
> sub ax, ax
> mov ds, ax
> mov bp, 0x7c00
>
> mov ax, 0x1FE0
>
El dom, 31-05-2009 a las 20:05 +0200, Vladimir 'phcoder' Serbinenko
escribió:
> > The only semi-rational action we can take is to reverse the mapping
> > _only_ if %dl still contains the mapped data we passed into the int13
> > handler, but that leaves the question - how do we know that some 0x81 i
> Do not waste your time doing so. There are many other functions that
> return data in DX, some of them specific to certain systems or TSRs -
> check Ralf Brown's Interrupt List [0] for a possibly very incomplete
> reference. The fuss about DS, BS, CX and DX being preserved is quite
> false,
It's
El dom, 31-05-2009 a las 18:00 +0200, Vladimir 'phcoder' Serbinenko
escribió:
> 2009/5/31 Javier Martín :
> > El dom, 31-05-2009 a las 13:36 +0200, Vladimir 'phcoder' Serbinenko
> > escribió:
> >> Doing some tests I discovered that freedos MBR (but not the
> >> bootsector) relies on %dl being prese
2009/5/31 Javier Martín :
> El dom, 31-05-2009 a las 13:36 +0200, Vladimir 'phcoder' Serbinenko
> escribió:
>> 2009/5/31 Javier Martín :
>> > El sáb, 30-05-2009 a las 17:28 +0200, Vladimir 'phcoder' Serbinenko
>> > escribió:
>> > Put it that way, I agree with your change. To the scrapper with
>> >
El dom, 31-05-2009 a las 13:36 +0200, Vladimir 'phcoder' Serbinenko
escribió:
> 2009/5/31 Javier Martín :
> > El sáb, 30-05-2009 a las 17:28 +0200, Vladimir 'phcoder' Serbinenko
> > escribió:
> > Put it that way, I agree with your change. To the scrapper with
> > parse_biosdisk then!
> Sorry, I di
2009/5/31 Javier Martín :
> El sáb, 30-05-2009 a las 17:28 +0200, Vladimir 'phcoder' Serbinenko
> escribió:
>> >> > I'm fine with the change from "const void" to "const char", but we need
>> >> > to remove a preceding comment about void labels.
>> >> It's not that I'm opposed to void in principle.
El sáb, 30-05-2009 a las 17:28 +0200, Vladimir 'phcoder' Serbinenko
escribió:
> >> > I'm fine with the change from "const void" to "const char", but we need
> >> > to remove a preceding comment about void labels.
> >> It's not that I'm opposed to void in principle. Just using the same
> >> construc
>> > I'm fine with the change from "const void" to "const char", but we need
>> > to remove a preceding comment about void labels.
>> It's not that I'm opposed to void in principle. Just using the same
>> constructions to do the same things in different files makes code
>> easier to learn and port
El jue, 14-05-2009 a las 20:38 +0200, Vladimir 'phcoder' Serbinenko
escribió:
> >> > I'm fine with the change from "const void" to "const char", but we need
> >> > to remove a preceding comment about void labels.
> >> It's not that I'm opposed to void in principle. Just using the same
> >> construc
>> > I'm fine with the change from "const void" to "const char", but we need
>> > to remove a preceding comment about void labels.
>> It's not that I'm opposed to void in principle. Just using the same
>> constructions to do the same things in different files makes code
>> easier to learn and port
On Thu, 2009-05-14 at 17:01 +0200, Vladimir 'phcoder' Serbinenko wrote:
> On Thu, May 14, 2009 at 4:03 PM, Pavel Roskin wrote:
> > I'm sorry, I didn't realize you were opposed to the patch. I assumed
> > that you just wanted to make some improvements. Nobody was against the
> > drivemap command
On Thu, May 14, 2009 at 4:03 PM, Pavel Roskin wrote:
> On Thu, 2009-05-14 at 08:49 +0200, Vladimir 'phcoder' Serbinenko wrote:
>> Hello, I had two clear oppositions which weren't resolved. I don't
>> believe that merge patches screwing up the pendin oppositions is a
>> good practice. The oppositio
On Thu, 2009-05-14 at 08:53 +0200, Vladimir 'phcoder' Serbinenko wrote:
> > Some messages have been clarified. In particularly, biosdisk is called
> > osdisk now, as it's what the OS sees. I was thinking of "payload" or
> > "loadee" as more generic terms, but it can be confusing to the users.
>
On Thu, 2009-05-14 at 08:49 +0200, Vladimir 'phcoder' Serbinenko wrote:
> Hello, I had two clear oppositions which weren't resolved. I don't
> believe that merge patches screwing up the pendin oppositions is a
> good practice. The opposition about declaration is based on another
> handlers how it i
On Thu, May 14, 2009 at 3:51 AM, Pavel Roskin wrote:
> On Sat, 2009-05-09 at 17:42 +0200, Javier Martín wrote:
>
>> OK, I have a good feeling about this version of the patch. Most
>> importantly, it still works!!
>
> I have committed your patch after a cleanup. My changes were following:
>
> grub
Hello, I had two clear oppositions which weren't resolved. I don't
believe that merge patches screwing up the pendin oppositions is a
good practice. The opposition about declaration is based on another
handlers how it is used accross grub. Opposition about calling
biosdisk is technically relevant.
On Sat, 2009-05-09 at 17:42 +0200, Javier Martín wrote:
> OK, I have a good feeling about this version of the patch. Most
> importantly, it still works!!
I have committed your patch after a cleanup. My changes were following:
grub_drivemap_int13_handler_base and grub_drivemap_int13_handler have
El dom, 10-05-2009 a las 13:47 +0200, Vladimir 'phcoder' Serbinenko
escribió:
> I guess you were trying to say that the casts are _not_ needed
> if I
> declared it as such. What I'm trying to say is that in its
> only _direct_
> use (in memcpy), its "const v
Hello. Sorry for the delay, I was kept busy by making grub2 compile with
apples compiler. It already works just needs some testing and cleanup and
then I'll post a patch
> I don't see the advantage, particularly taking into account that the
> current code is very happy to treat it as a black box t
El sáb, 09-05-2009 a las 16:04 +0200, Vladimir 'phcoder' Serbinenko
escribió:
> Hello
>
> 2009/5/9 Javier Martín
> El sáb, 09-05-2009 a las 11:17 +0200, Vladimir 'phcoder'
> Serbinenko
> escribió:
> > +/* Realmode far ptr (2 * 16b) to the previous INT13h
>
Hello
2009/5/9 Javier Martín
> El sáb, 09-05-2009 a las 11:17 +0200, Vladimir 'phcoder' Serbinenko
> escribió:
> > +/* Realmode far ptr (2 * 16b) to the previous INT13h handler. */
> > +extern grub_uint32_t grub_drivemap_int13_oldhandler;
> > I prefer it to be 2 variables because of the way the
El sáb, 09-05-2009 a las 11:17 +0200, Vladimir 'phcoder' Serbinenko
escribió:
> +/* Realmode far ptr (2 * 16b) to the previous INT13h handler. */
> +extern grub_uint32_t grub_drivemap_int13_oldhandler;
> I prefer it to be 2 variables because of the way they interract so
> nobody would do somethin
+/* Realmode far ptr (2 * 16b) to the previous INT13h handler. */
+extern grub_uint32_t grub_drivemap_int13_oldhandler;
I prefer it to be 2 variables because of the way they interract so nobody
would do something like (char *) grub_drivemap_int13_oldhandler;
+/* The type "void" is used for importe
Here is a new version of the patch. As you suggested, "grub_symbol_t"
was replaced with "void". Also, drivemap.h no longer exists, its little
content integrated into drivemap.c. Last but not least, I've mostly
adopted your version of the assembly file (indenting, labels, etc.)
--
-- Lazy, Oblivio
On Mon, 2009-05-04 at 01:37 +0200, Javier Martín wrote:
> > The patch adds many trailing spaces. I suggest that you run GNU indent
> > on drivemap.c. It will take care of most of the trailing spaces.
> > Comments will still need to be fixed.
> >
> > Assembler files use different formatting in G
El dom, 03-05-2009 a las 16:59 -0400, Pavel Roskin escribió:
> On Sun, 2009-05-03 at 02:02 +0200, Javier Martín wrote:
> > I am glad to inform that, with the new version of the mmap patch,
> > drivemap now boots all my hd1 installs of:
> > - Windows XP (Pro x64)
> > - ReactOS
> > - FreeDOS
>
> I c
On Sun, 2009-05-03 at 02:02 +0200, Javier Martín wrote:
> I am glad to inform that, with the new version of the mmap patch,
> drivemap now boots all my hd1 installs of:
> - Windows XP (Pro x64)
> - ReactOS
> - FreeDOS
I confirm that 32-bit Windows XP is working too.
> I would suggest, however, th
On Sun, 2009-05-03 at 11:17 +0200, Vladimir 'phcoder' Serbinenko wrote:
> I would suggest, however, that the return type of
> grub_mmap_malign_and_register be changed to void* from char*,
> just like
> the return type from malloc, because it's the meaningful data
>
Hello. Now I just quickly answer you questions. Will review the patch a bit
later (probably still today)
2009/5/3 Javier Martín
> I am glad to inform that, with the new version of the mmap patch,
> drivemap now boots all my hd1 installs of:
> - Windows XP (Pro x64)
> - ReactOS
> - FreeDOS
>
> I
I am glad to inform that, with the new version of the mmap patch,
drivemap now boots all my hd1 installs of:
- Windows XP (Pro x64)
- ReactOS
- FreeDOS
I would suggest, however, that the return type of
grub_mmap_malign_and_register be changed to void* from char*, just like
the return type from mal
>
> we tell it not to touch the 640K-1M area?
>
On most machines this range is in ROM and VGA buffer so FreeDOS doesn't
touch it anyway
>
> --
> -- Lazy, Oblivious, Rational Disaster -- Habbit
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> http
El vie, 17-04-2009 a las 20:01 -0400, John Stanley escribió:
> 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 simp
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 docu
On Sat, Apr 18, 2009 at 1:12 AM, John Stanley 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 pa
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 better.
In addition, in
Thank you for the feedback on my patch. Also I'll add a function to
allocation and register map for hook. Also
> The preboot hooks patch works beautifully.
Don't forget to make cleanup function in case loader fails
> However, mmap causes some
> sort of glitch that makes FreeDOS (one of my three
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, preboot
hooks and mmap. I've adapted drivemap to use them both, and I'm
polishing some rough ed
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
John Stanley wrote:
I'd be happy to sign a copywrite statement, no problem -- how do I go
about it ?
Is this what you're referring to:
/* BDA off
I'd be happy to sign a copywrite statement, no problem -- how do I go
about it ?
Is this what you're referring to:
/* BDA offset 0x13 contains the top of conventional memory, in
kiB. */
grub_uint16_t *bpa_freekb = (grub_uint16_t*)0x0413;
.
.
*bpa_freekb -= payl
If you want your code to be incorporated you need to sign the copyright
assignment.
John Stanley wrote:
I have also incorporated your mmap services patch as well (again with
minor mods to build in r2106). My question at this point, is how best to
incorporate mmap services into drivemap. I see
I have your preboot hooks patch incorporated into grub-r2106 along with
a suitably updated version of drivemap, which remains flawlessly working
with 2nd-harddisk Windows XP boots (grub being installed on the 1st
harddisk along with Linux). Had to make a few minor changes to the
preboot hooks
I haven't yet looked in depth in drivemap patch but it has some
problems. It uses preboot hook interface for which I proposed an update
in my recent patch "preboot hooks". Also it doesn't update memorymap
correctly. For this it should use my "mmap services" interface
John Stanley wrote:
Thanks
Thanks Felix,
Hurm.. Well, if anyone is interested, I have just made a couple of
additional updates to the drivemap.path.8 code,
and now with r2104 the "unaligned pointer" issue is gone, and it is
working great on my systems. I can post the patch if you or anyone else
is interested.
John
Fe
Am Montag, den 13.04.2009, 21:03 -0400 schrieb John Stanley:
> Hi all,
> I was wondering what the current status of a grub2 port of the grub-0.97
> "map" and "rootnoverify" commands is? I have found some work done to
> this end in the "drivemap.patch" work, but I find nothing more recent
> than
Hi all,
I was wondering what the current status of a grub2 port of the grub-0.97
"map" and "rootnoverify" commands is? I have found some work done to
this end in the "drivemap.patch" work, but I find nothing more recent
than drivemap.patch.8 dated around Aug 2008.
I have taken drivemap.patc
54 matches
Mail list logo
