Re: [PATCH] iso9660 UUID support by using the creation date/time
On Fri, Sep 05, 2008 at 07:02:57PM +0200, Felix Zielcke wrote: > Am Sonntag, den 31.08.2008, 20:55 +0200 schrieb Felix Zielcke: > > > Args, I'm blind :( > > I copied the function from fs/ntfs.c and there it says `grub_malloc 16 + > > sizeof (\0)' > > With "" it's useless so .5 attached so it doestn't get lost :) > > Bean did only the joliet support and he already said it looks okay. > But Marco I'd like to have your comment because you initially coded the > iso9660 support :) The patch is completely non-intrusive, and nobody had objections or other comments for a while. I think it's fine if you check it in. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] iso9660 UUID support by using the creation date/time
Am Samstag, den 06.09.2008, 13:11 +0200 schrieb Robert Millan: > On Fri, Sep 05, 2008 at 07:02:57PM +0200, Felix Zielcke wrote: > > Bean did only the joliet support and he already said it looks okay. > > But Marco I'd like to have your comment because you initially coded the > > iso9660 support :) > > The patch is completely non-intrusive, and nobody had objections or other > comments for a while. I think it's fine if you check it in. Thanks Robert commited :) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] general-usage real-mode loader
On Fri, Sep 05, 2008 at 07:27:51PM +0200, phcoder wrote: > Hello. A long time ago I written a C+asm code which loads any given code > at any real-mode location, then puts machine in correct state and then > launches the kernel. I can modify this code to suit GRUB2. Then loading > realmode kernel would work like this: > 1) copy helper asm to last kb of lower memory > 2) jump to the helper > 3) helper copies from upper memory the kernel > 4) turn A10 bug back on if necessary > 5) go to RM > 6) prepare registers > 7) jump to the kernel > > This protocol is very flexible and as such could be used by all loaders > which load kernel in realmode or even in PM (skip step 5, do steps 6-7 > in 32-bit mode) except for changing page tables. Such a helper can be > easily implemented as module and so help us removing asm-parts of > loaders from the kernel. If I recieve greenlight for it, I implement it. Maybe I'm confusing this with something else, but isn't this what both Bean and Vesa implemented separately, and are currently discussing in another thread? (the goal there was to move BIOS wrappers out of kern/i386/pc/startup.S) -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: floating point exception in disk/raid.c:206
Commited. Am Donnerstag, den 04.09.2008, 21:22 +0200 schrieb Felix Zielcke: > Am Donnerstag, den 04.09.2008, 11:29 +0200 schrieb Felix Zielcke: > > > The easiest fix would be probable to just set chunk_size to for example > > 64. > > Attached patch does it, but maybe you have a better/other idea? > > Thanks to Bean on IRC. > I think this is now the right place to do it, at end of insert_array in > case of a new one. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Idea: Move kernel to upper memory
On Fri, Sep 5, 2008 at 12:49 AM, Robert Millan <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 03, 2008 at 04:15:33PM +0530, BVK Chaitanya wrote:
>>
>> Since payload(s) needs to be present at their precise positions only
>> after the boot command, we can always deterministically /schedule/
>> memmove operation to be executed as part of boot command.
>>
>> Since boot command is the last command executed by GRUB (correct me if
>> not), we can overwrite any GRUB code/data at that point. This also
>> needs boot command to exist in low memory.
>
> This is already done. See grub_multiboot_{forward,backward}_relocator
> variables and how they're used in the multiboot loader.
>
OK, fine :-)
--
bvk-chaitanya
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC]swapfso and "ioctl" function for filesystems
Robert Millan wrote: > On Thu, Sep 04, 2008 at 11:27:20PM +0200, phcoder wrote: >>> Could this be made more transparent? For example, with a variable. >>> >> Here perhaps it could be. But in other usage cases like putting the dos >> boot files into the right place or doing swapfso it couldn't. > > We intentionally don't support filesystem writing. This was discussed before, > I think. > Well I see no reason why not to allow such feature to be made by external modules. Another usage case is ext3cow snapshots. Even if the snapshot can be chosen by a variable to list the snapshots you need a function. >>> Also, I'm worried that this occupies core image size for non-critical >>> functionality. >>> >> If filesystem module doesn't use this feature it just adds a zero >> pointer to grub_fs structure. > > Yes, but what if it does? > then for registering the functions it needs 4+(4+d)*n bytes. Where n is the number of functions and d the size of identifier. As such we can choose: a 4-byte enum, a string or a GUID-like system with 8,12 (my preferance) or 16-byte long identifier. Also if module is split into 2 (essential and not-essential) then the registering of functions can be handled by not-essential module >> may be implemented in an extra module >> (like ntfscomp) or there could be 2 modules for the same filesystem: >> basic and advanced one. > > 2 modules for the same filesystem can lead to trouble; I don't think GRUB > can handle this situation properly (for example, if you need ext2.mod to > access $prefix, how to you replace it with the new module, which needs to be > loaded precisely from $prefix?). I checked module loading code: it loads the module completely to the memory and only then launches it. So basically it's not a problem > > An extra module would be saner, IMO. > I also think so Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] general-usage real-mode loader
I checked the archive found the thread "Idea: Move kernel to upper memory". But what is discussed there is much more general about general memory layout. Here I wanted to speak about just one function. Vladimir 'phcoder' Serbinenko Robert Millan wrote: > On Fri, Sep 05, 2008 at 07:27:51PM +0200, phcoder wrote: >> Hello. A long time ago I written a C+asm code which loads any given code >> at any real-mode location, then puts machine in correct state and then >> launches the kernel. I can modify this code to suit GRUB2. Then loading >> realmode kernel would work like this: >> 1) copy helper asm to last kb of lower memory >> 2) jump to the helper >> 3) helper copies from upper memory the kernel >> 4) turn A10 bug back on if necessary >> 5) go to RM >> 6) prepare registers >> 7) jump to the kernel >> >> This protocol is very flexible and as such could be used by all loaders >> which load kernel in realmode or even in PM (skip step 5, do steps 6-7 >> in 32-bit mode) except for changing page tables. Such a helper can be >> easily implemented as module and so help us removing asm-parts of >> loaders from the kernel. If I recieve greenlight for it, I implement it. > > Maybe I'm confusing this with something else, but isn't this what both Bean > and Vesa implemented separately, and are currently discussing in another > thread? > > (the goal there was to move BIOS wrappers out of kern/i386/pc/startup.S) > ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
