A version with biosdisk, pc and ext2
before: 24800
after: 24687
But another matter is expandability - preboot hooks are important.
Without them implementation of sendkey or map is impossible. And adding
preboot hooks to kernel would increase its size by 150-200 bytes.
Also I don't see how this c
On Mon, Sep 08, 2008 at 10:11:33PM +0200, Javier Martín wrote:
> El lun, 08-09-2008 a las 22:48 +0300, Vesa Jääskeläinen escribió:
> > phcoder wrote:
> > > Hello. As I said in another email there is no need for it. I send a
> > > patch for it.
> >
> > Doesn't this break our rescue mode ?
> How wou
On Mon, Sep 08, 2008 at 10:59:02PM +0200, Javier Martín wrote:
> El lun, 08-09-2008 a las 23:25 +0300, Vesa Jääskeläinen escribió:
> > Javier Martín wrote:
> > > El lun, 08-09-2008 a las 22:48 +0300, Vesa Jääskeläinen escribió:
> > >> phcoder wrote:
> > >>> Hello. As I said in another email there i
I did. The discussion seems to simply have died out without any official
response
Thanks
Vladimir 'phcoder' Serbinenko
Vesa Jääskeläinen wrote:
phcoder wrote:
Hello,all. I was busy studying so wasn't watching the list. Is there a
particular reason why my patch still isn't incorporated?
Perhap
phcoder wrote:
> Hello,all. I was busy studying so wasn't watching the list. Is there a
> particular reason why my patch still isn't incorporated?
Perhaps we didn't like the move of loader/boot core functionality out of
kernel?
And I do not remember you describing in detail about interfaces and
f
Hello,all. I was busy studying so wasn't watching the list. Is there a
particular reason why my patch still isn't incorporated?
Thanks
phcoder
Javier Martín wrote:
El lun, 08-09-2008 a las 23:25 +0300, Vesa Jääskeläinen escribió:
Javier Martín wrote:
El lun, 08-09-2008 a las 22:48 +0300, Vesa
El lun, 08-09-2008 a las 23:25 +0300, Vesa Jääskeläinen escribió:
> Javier Martín wrote:
> > El lun, 08-09-2008 a las 22:48 +0300, Vesa Jääskeläinen escribió:
> >> phcoder wrote:
> >>> Hello. As I said in another email there is no need for it. I send a
> >>> patch for it.
> >> Doesn't this break ou
Javier Martín wrote:
> El lun, 08-09-2008 a las 22:48 +0300, Vesa Jääskeläinen escribió:
>> phcoder wrote:
>>> Hello. As I said in another email there is no need for it. I send a
>>> patch for it.
>> Doesn't this break our rescue mode ?
> How would it? As with other commands, there would be two ver
El lun, 08-09-2008 a las 22:48 +0300, Vesa Jääskeläinen escribió:
> phcoder wrote:
> > Hello. As I said in another email there is no need for it. I send a
> > patch for it.
>
> Doesn't this break our rescue mode ?
How would it? As with other commands, there would be two versions of it,
one for res
phcoder wrote:
> Hello. As I said in another email there is no need for it. I send a
> patch for it.
Doesn't this break our rescue mode ?
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
El vie, 05-09-2008 a las 18:13 +0200, phcoder escribió:
> Hello. As I said in another email there is no need for it. I send a
> patch for it.
Well, I won't deny the patch is clever and looks good (I haven't tested
it yet). However, taking the generic "boot" command out of kernel and
leaving the sev
Hello. As I said in another email there is no need for it. I send a
patch for it.
Vladimir 'phcoder' Serbinenko
Javier Martín wrote:
> El mié, 03-09-2008 a las 20:53 +0300, Vesa Jääskeläinen escribió:
>> phcoder wrote:
>>> Hello. In this case we can transfer the whole functionality located in
>>> k
El mié, 03-09-2008 a las 20:53 +0300, Vesa Jääskeläinen escribió:
> phcoder wrote:
> > Hello. In this case we can transfer the whole functionality located in
> > kern/loader.c to a dedicated module boot.mod. This module will also
> > register "boot" command. In this way the encapsulation won't be b
Vesa Jääskeläinen wrote:
> phcoder wrote:
>> Hello. In this case we can transfer the whole functionality located in
>> kern/loader.c to a dedicated module boot.mod. This module will also
>> register "boot" command. In this way the encapsulation won't be broken
>> and kernel will become even smaller
phcoder wrote:
> Hello. In this case we can transfer the whole functionality located in
> kern/loader.c to a dedicated module boot.mod. This module will also
> register "boot" command. In this way the encapsulation won't be broken
> and kernel will become even smaller.
Remember that realmode code
Hello. In this case we can transfer the whole functionality located in
kern/loader.c to a dedicated module boot.mod. This module will also
register "boot" command. In this way the encapsulation won't be broken
and kernel will become even smaller.
Vladimir 'phcoder' Serbinenko
Vesa Jääskeläinen wrot
Am Mittwoch, den 03.09.2008, 19:23 +0200 schrieb Javier Martín:
> * I doubt: is the current DL system in GRUB able to hand dependencies
> directly? In other words, is our "insmod" more like modprobe or Linux
> insmod? This affects the handling of "insmod drivemap" or "insmod
> sendkey" if preboot.
El mié, 03-09-2008 a las 20:07 +0300, Vesa Jääskeläinen escribió:
> Hi,
>
> How about following (may not be syntaxically correct):
>
> In kernel:
>
> /* Variable holding pointer to preboot hook function. */
> preboot_hook:
> .long 0
>
> ...
> /* Check if there is preboot hook ins
Hi,
How about following (may not be syntaxically correct):
In kernel:
/* Variable holding pointer to preboot hook function. */
preboot_hook:
.long 0
...
/* Check if there is preboot hook installed. */
movlpreboot_hook, %eax
testl %eax, %eax
jne
Hi again,
El mié, 03-09-2008 a las 11:10 +0200, phcoder escribió:
> >> I'll have a look at it but not sure to find anything since I'm not
> >> familiar with either ata or reiserfs internal structure.
> > I was not suggesting that it was you or me who did it; it was a general
> > "call" for GRUB de
On Wednesday 03 September 2008, Javier Martín wrote:
> El mié, 03-09-2008 a las 02:08 +0200, phcoder escribió:
> > Hello, again.
> >
> > Javier Martín wrote:
> > > We have 63 sectors = 32256 bytes (sectors range from 0 to 63 and the
> > > first is used by the MBR).
> >
> > I've just rechecked on my
Javier Martín wrote:
> El mié, 03-09-2008 a las 02:08 +0200, phcoder escribió:
>> Hello, again.
>> Javier Martín wrote:
>>> We have 63 sectors = 32256 bytes (sectors range from 0 to 63 and the
>>> first is used by the MBR).
>>>
>> I've just rechecked on my system. My first partition begins at secto
Am Mittwoch, den 03.09.2008, 01:38 +0200 schrieb Javier Martín:
> But ata and reiserfs
> are quite the bloaters... The reiserfs case is particularly strange: in
> the linux kernel, the reiserfs module is 50% bigger than ext3.ko; while
> in GRUB, reiserfs.mod (without journaling) is twice the size o
El mié, 03-09-2008 a las 02:08 +0200, phcoder escribió:
> Hello, again.
> Javier Martín wrote:
> > We have 63 sectors = 32256 bytes (sectors range from 0 to 63 and the
> > first is used by the MBR).
> >
> I've just rechecked on my system. My first partition begins at sector
> number 63. This is th
Hello, again.
Javier Martín wrote:
> We have 63 sectors = 32256 bytes (sectors range from 0 to 63 and the
> first is used by the MBR).
>
I've just rechecked on my system. My first partition begins at sector
number 63. This is the value I've seen at most systems. So last usable
sector is 62. Sector
El mié, 03-09-2008 a las 00:22 +0200, phcoder escribió:
> > Here is my "version" of your patch, without the double indirection and
> > the strange plays. The overhead is 103 bytes without the error line
> > against 63 of yours, but I really think that the symmetric and
> > understandable handling o
Javier Martín wrote:
> El mar, 02-09-2008 a las 20:39 +0200, phcoder escribió:
>> +void
>> +grub_loader_remove_preboot (void *p)
>> +{
>> + if (!p)
>> +return;
>> + *(PREBOOT_HND(p)->prev_pointer)=PREBOOT_HND(p)->next;
> This line will "crash" if p is the head of the list (with prev_pointer
El mar, 02-09-2008 a las 20:39 +0200, phcoder escribió:
> +void
> +grub_loader_remove_preboot (void *p)
> +{
> + if (!p)
> +return;
> + *(PREBOOT_HND(p)->prev_pointer)=PREBOOT_HND(p)->next;
This line will "crash" if p is the head of the list (with prev_pointer
being 0). I quote crash because
phcoder wrote:
> Well the interface is as we described: the module gives a callback
> function which will be called before launching boot function. This
> interface is enough for both (and probaly many other) needs. The only
> problem is that callback functions can conflict with each other and with
Well the interface is as we described: the module gives a callback
function which will be called before launching boot function. This
interface is enough for both (and probaly many other) needs. The only
problem is that callback functions can conflict with each other and with
boot function. E.g. if
Javier Martín wrote:
> But you negate any performance gain when you _do_ traverse the list to
> add an entry to it instead of just make it the new head as I do.
> Besides, even for that, double indirection should be avoided in the
> structure previous pointer because it makes things oh-so-incredibl
El mar, 02-09-2008 a las 17:58 +0200, phcoder escribió:
> > but it seems terser
> > than mine even though it's a bit more difficult to understand because
> > you use double pointers to avoid my handling of the head case. I don't
> > understand the purpose of doubly-linking the list though...
> >
>
Hi,
Now that we have two use cases for this. I would propose that we first
fine tune interface and then use common one. This is the critical part
of the design and needs to be solved. I wasn't really convinced with the
other proposed interface.
So if you two could propose improved one that can ha
Sorry, forgot to attach
phcoder wrote:
> Hello, again
> I had a look at your patch. In some mail it was suggested that kernel
> patch should be split from module that uses it. So I resend the kernel
> part of my patch. Another question is whether we need some kind of
> abortion procedure (like in y
Hello, again
I had a look at your patch. In some mail it was suggested that kernel
patch should be split from module that uses it. So I resend the kernel
part of my patch. Another question is whether we need some kind of
abortion procedure (like in your patch) if a preboot hook fails.
Javier Martín
El mar, 02-09-2008 a las 16:23 +0200, phcoder escribió:
> For implementing this functionality I needed my function to be executed
> right before booting. To do it I added a simple interface for adding
> "preboot" functions:
> struct grub_preboot_t *grub_loader_add_preboot (grub_err_t
> (*preboot_fu
36 matches
Mail list logo
