Re: [PATCH] Fix warning in fs/xfs.c

[Cesare Leonardi]

Marco Gerards wrote:

Pavel Roskin <[EMAIL PROTECTED]> writes:


On Thu, 2008-07-03 at 20:21 +0200, Marco Gerards wrote:

Pavel Roskin <[EMAIL PROTECTED]> writes:


ChangeLog:
* fs/xfs.c (struct grub_xfs_dir_header): Use names similar to
those in Linux XFS code.  Provide a way to access 64-bit parent
inode.
(grub_xfs_iterate_dir): Use the new names.  Avoid reading past
the end of struct grub_xfs_dir_header.

*please* do not look at Linux code or whatever *and* contribute to
 GRUB.  It might cause copyright troubles I will have to deal with :-/

I just tried to make names similar without copying any code.  But it's a
useful reminder.


What I meant is that even *looking* at code might cause problems.
People can claim you have stolen their ideas.  That would essentially
mean the same as copying code.  I just want to avoid such problems at
beforehand.


But one of the best aspect of the free software is exactly that you 
could look inside other's code and reuse it and its ideas.
Would be a problem if you look the source of a program covered by NDA, 
or by some other closed license, but with Linux kernel?? If you couldn't 
look inside a GPL2 project then it would be a loss of the free software 
and the GPL3. And you have to reinvent something that others has already 
done well...


Furthermore, AFAIK, the problem of protecting code implementation is 
covered by copyright, while protecting ideas is a patent job. Now, Linux 
is GPL2 and it's not encumbered by patents, so what's the problem?


Regards.

Cesare.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: device.map (Re: Next release?)

[Pavel Roskin]

On Sat, 2008-07-19 at 17:14 +0200, Robert Millan wrote:

> > As I understand it, there are two cases where we have to hardcode the
> > drive number.
> > 
> > 1) MBR and core.img (embedded or not) are on different drives.
> 
> If embedded, then they're not different drives (core.img is put right after
> MBR).
> 
> Otherwise it's a no-go, and device.map won't solve your problem since it's
> merely guessing which drive it'll be.  I think it's better to detect this at
> install time and fail, than make the user rely on our guesswork.

We could do it in theory.  Even with device.map.  It's not much more
insane than having /boot/grub on a different drive.  The boot drive can
have a "bad" geometry with too few sectors per track.  Or it could be
formatted as one partition.  Or it could be a slow floppy drive.  Or it
could be in ROM.  Or BIOS may not report the boot drive correctly.

How can we fail to support this configuration and claim that the
elimination of device.map would reduce flexibility?  If we card about
flexibility, let's support hardcoding the boot drive into the
bootloader.

Actually, the groundwork is already present in grub-setup and the
bootsector, but grub-install doesn't have an option to force a drive for
core.img embedding.

> > 2) core.img and /boot/grub are on different drives.
> > 
> > The second case can be mitigated because core.img can search all
> > available drives.  We can even tell it whether to search only hard
> > drives or only floppies.  After switching to lzma, we have some space in
> > core.img we can use for that logic.
> 
> This is mostly implemented already.  I sent a proof of concept in a mail
> titled "[PATCH] disk/fs_uuid.c".
> 
> It will only search hard drives unless no match is found (in that case your
> boot is broken, so you wouldn't care much that floppy is being probed ;-)

Then all be need it to have an option in grub-install to enable this
logic.

-- 
Regards,
Pavel Roskin


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Next release?

[Pavel Roskin]

On Sat, 2008-07-19 at 22:16 +0200, Yoshinori K. Okuji wrote:

> I am totally against ripping off device.map. Pavel's idea is too
> idealistic, 
> and that regresses the flexibility.

Actually, it could be said that having device.map regresses flexibility.
Suppose I want to install GRUB on a flash drive that is seen
as /dev/sdb.  I need to add /dev/sdb to device.map even though I'm not
going to see that flash drive again.  I also need to check the options
to ensure that everything is installed on the flash drive and nothing is
installed elsewhere.

Suppose that we don't have device.map.  Then I don't need to add entries
for temporary devices.  Also, I won't be able to create a cross-drive
configuration by accident, simple because it won't be allowed by
default.

If you think that device.map is beneficial for cross-device installs,
then we can have an option to enable cross-device installs, that would
also enable device.map.  Single-drive installs don't need to make any
assumptions about the BIOS numbers, and thus won't use device.map in any
way.

Actually, I think that even cross-device installs should rely on probing
the relevant drives rather than on cached information.  But we can
discuss and implement it separately.

-- 
Regards,
Pavel Roskin


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Strong Crypto Support for GRUB2

[Simon Peter]

> > What's missing to get my code into GRUB2 mainline?
> I think you'll have to assign copyright to the FSF.

What part of it?

I learned that Michael Gorven already replaced the problematic parts
(RIPEMD and AES) with versions from libgcrypt. The rest of the code is
all GPL3. Is it about the extra copyright line with my name in it?

Simon


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Kernel fixes for Cygwin

[Pavel Roskin]

On Mon, 2008-07-21 at 19:23 +0200, Javier Martín wrote:
> El lun, 21-07-2008 a las 13:03 -0400, Pavel Roskin escribió:

> > I think it's important to have a consistent format for modules.
> I thought that two hours ago, but now I find no advantage other than the
> sharing of modules between similar computers.

Sharing modules is unsafe.

My concern is sharing the code.  If we use different formats, there are
more place for bugs to hide or to appear.  There is more work to test
changes that can affect module loading.

-- 
Regards,
Pavel Roskin


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Idea: elimination of the normal mode (revised version)

[Bean]

On Tue, Jul 22, 2008 at 2:03 AM, Bean <[EMAIL PROTECTED]> wrote:
> Your idea seems fine, but there is a slightly efficiency issue. For
> example, when we need to call a function in the handler, we need to
> acquire it using name. We need to do this in every call, as the
> handler could be changed next time.
>
> My suggestion is to use function pointer instead of name, for example,
>
> grub_handler_register (&grub_handler_input_head, my_handler);
>
> Then we can always use grub_handler_input_head->getkey() to read a key.
>
> The drawback is that we need to define grub_handler_**_head as global 
> variable.
>

Hi,

Ok, I come up with a mixed solution. We can still register handler
using string, like this:

grub_handler_register ("input", my_input_handler);

We don't need grub_handler_add. Whenever it sees a new string,
grub_handler_register would create a item in the handler table.

To get the handler, we use:

grub_get_handler ("input", &local_input_handler_head);

The handler is managed as linked list, the head always points to
current selection, so we can use local_input_handler_head to call the
handler function.

To reduce unnecessary grub_get_handler calls, we export important
handler head as global variable, for example, we can use the following
in grub_main:

grub_get_handler ("input", &grub_input_handler_head);
grub_get_handler ("output", &grub_output_handler_head);
...

Other modules can use grub_input_handler_head directly to access input
handlers, but for custom handler such as "foo", they need to use
grub_get_handler to get the handler pointer.

-- 
Bean


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH] Home-End keys in menu

[Carles Pina i Estany]

Hello,

Last weekend we talked about "menu loop" (wrapping):
http://lists.gnu.org/archive/html/grub-devel/2008-07/msg00319.html

Conclusion: people here don't like it (we could discuss for ages, I
think :-) )

Second proposal that maybe was hidden in so much text: to make it to
work Home and End keys. Patch is attached. Do you need a more formal
changelog for this? Adds Home and End key moving.
Comments are welcomed.

Commend: I think that would be possible to change "case 14" by "case
GRUB_TERM_DOWN"; and "case 16" by "case GRUB_TERM_UP" in normal/menu.c
line 400 aprox. These constants are defined in include/grub/term.h. I
don't send a patch because it's in the same "zone" than attached patch
and it's easy-easy.

Thanks for your patience,

-- 
Carles Pina i EstanyGPG id: 0x8CBDAE64
http://pinux.info   Manresa - Barcelona
Index: normal/menu.c
===
--- normal/menu.c	(revision 1718)
+++ normal/menu.c	(working copy)
@@ -405,6 +405,22 @@
 	  
 	  switch (c)
 	{
+case GRUB_TERM_HOME:
+	   first=0;
+	   offset=0;
+	   print_entries (menu, first, offset);
+	   break;
+
+	case GRUB_TERM_END:
+	  offset = menu->size - 1;
+	  if (offset > GRUB_TERM_NUM_ENTRIES - 1)
+		{
+  first = offset - (GRUB_TERM_NUM_ENTRIES - 1);
+		  offset = GRUB_TERM_NUM_ENTRIES - 1;
+		}
+		print_entries (menu, first, offset);
+	  break;
+
 	case 16:
 	case '^':
 	  if (offset > 0)
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Idea: elimination of the normal mode (revised version)

[Bean]

On Tue, Jul 22, 2008 at 1:27 AM, Marco Gerards <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Bean <[EMAIL PROTECTED]> writes:
>
>> On Mon, Jul 21, 2008 at 4:02 AM, Marco Gerards <[EMAIL PROTECTED]> wrote:
>>> Hi,
>>>
>>> Bean <[EMAIL PROTECTED]> writes:
>>>
 First of all, we can still keep rescue and normal command. But instead
 of depending on normal.mod, normal command depends on module arg,
 which is an option parser. Also, these two type of commands are of the
 same command set. In fact, module arg is implemented as a pre parser,
 which goes through the list of arguments and extract the options. In
 the case of rescue command, the pre parser field is null, which means
 it wants to parse options itself.
>>>
>>> pre parser?
>>
>> Maybe not the best word, the idea is that normal command is just like
>> rescue command, except that it goes through an extra parser that
>> convert options to grub_arg_list.
>
> Sorry, but I still don't understand this.  Do you propose:
> svn move normal/arg.c kern/arg.c
>
> ?
>
> If you propose a stripped down argument parser, how do arguments
> parsers differ amongst each other?
>

Actually, no need to move normal/arg.c to kernel, it can be a
standalone module. Normal command depend on it, while rescue command
don't.

there is only one argument parser, it's job is to scan the argument
for options like -f, --file and convert them to grub_arg_list, so that
the command handler don't have to parse option itself.

>
> Seems ok to me.
>
> Although what if we want additional handlers.  Like image readers or
> so?  We do not need to centralize this.  What about this:
>
> handler.c:
>
> grub_handler_t
> grub_handler_add (const char *name)
> {
> ...
> }
>
> grub_err_t
> grub_handler_remove (const char *name)
> {
>  ...
>  if (module uses handler)
>   return grub_error (...);
>  ...
> }
>
>
> /* NAME is the name of the handler, HANDLER the handler struct.  */
> grub_err_t
> grub_handler_register (const char *name, grub_handler_t handler)
> {
> ...
> }
>
>
> /* NAME is the name of the handler, HANDLER the handler struct.  */
> grub_err_t
> grub_handler_deregister (const char *name, grub_handler_t handler)
> {
> ...
> }
>
>
> /* HANDLER the handler struct.  Hook the hook function.  */
> grub_err_t
> grub_handler_register (grub_handler_t handler,
>   int (*hook) (grub_handler_t handler))
> {
> ...
> }
>
>
> handler.h:
>
> struct grub_handler
> {
>  struct grub_handler *next;
>  const char *name;
> };
>
> #define GRUB_CREATE_HANDLER_H(name, interfaces) \
> grub_err_t grub_##name##_register (struct grub_##name##_handler h);
>
> (same for the other functions)
>
> #define GRUB_CREATE_HANDLER_FUNCS(name, interfaces)  \
> grub_err_t   \
> grub_##name##_register (struct grub_##name##_handler h); \
> {\
>  grub_handler_register (name, &h->handler);
> }
>
> (same for other functions)
>
>
> So the handler framework is opaque to the user.  The user just works
> with this like it works now.  For example:
>
> foo.h:
>
> struct grub_foo
> {
>  /* This is *required*.  */
>  grub_handler_t handle;
>
>  /* Every FOO needs to foo.  */
>  int (*foo) (int bar);
> };
>
> GRUB_CREATE_HANDLER_T ("foo", struct grub_foo);
>
> this creates all prototypes
>
> foo.c:
>
> GRUB_CREATE_HANDLER ("foo", struct grub_foo);
>
> this creates functions that are very light and are mainly there to
> cast the structs back and forth so we can do type checking and get
> sane warnings and maximal cleaness.  Furthermore, users can now use:
>
> grub_foo_register (...);
>
> ^^ Every foo can register itself
>
> grub_foo_iterate (...);
>
> ^^ You can iterate over every foo
>
> The only "weird" thing is that when you register a handler, you have
> to know its name.  For example disk.c would do:
>
>  {
>   err = grub_handler_add ("disk");
>   ...
>  }
>
>
> So as a summary:
>
> grub_handler_add will be used to add new handler lists,
> grub_handler_remove will remove them
>
> grub_handler_register will register specific handlers (like disk
> handlers), a macro can be used to add a wrapper that passes along the
> name.  grub_handler_register can fill in the mandatory member "handle"
> such that later on the name is not required anymore.  Requiring
> strings only at register time is not very expensive.
>
> Sorry for the crappy code, but hopefully you get the idea, otherwise I
> can hack a bit or comment on your patches :-)
>

Your idea seems fine, but there is a slightly efficiency issue. For
example, when we need to call a function in the handler, we need to
acquire it using name. We need to do this in every call, as the
handler could be changed next time.

My suggestion is to use function pointer instead of name, for example,

grub_handler_register (&grub_handler_input_head, my_handler);

Then we can always use grub_handler_input_head->getkey() to read a key.

The drawback is that we need to define g

Re: Idea: elimination of the normal mode (revised version)

[Marco Gerards]

Hi,

Bean <[EMAIL PROTECTED]> writes:

> On Mon, Jul 21, 2008 at 4:02 AM, Marco Gerards <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> Bean <[EMAIL PROTECTED]> writes:
>>
>>> First of all, we can still keep rescue and normal command. But instead
>>> of depending on normal.mod, normal command depends on module arg,
>>> which is an option parser. Also, these two type of commands are of the
>>> same command set. In fact, module arg is implemented as a pre parser,
>>> which goes through the list of arguments and extract the options. In
>>> the case of rescue command, the pre parser field is null, which means
>>> it wants to parse options itself.
>>
>> pre parser?
>
> Maybe not the best word, the idea is that normal command is just like
> rescue command, except that it goes through an extra parser that
> convert options to grub_arg_list.

Sorry, but I still don't understand this.  Do you propose:
svn move normal/arg.c kern/arg.c

?

If you propose a stripped down argument parser, how do arguments
parsers differ amongst each other?  

>>> Then, I think of a new structure to represent all configurable
>>> handlers of grub. Different types of handler have different fields,
>>> but they all share a command header:
>>
>> What is a handler and what are its responsibilities?
>
> Actually, handler is a genetic term. For terminal, there is grub_term.
> For video, there is grub_video_adapter. They're similar in operation.
> For example, there can have multiple objects, but only one is active,
> they all have basic field like init, fini, next, name. They can be
> handled by the same function. I also extend this concept to other
> objects, like script engine, console and menu interface.

Right...

>>> struct grub_handler
>>> {
>>>   .next,
>>>   .name,
>>>   .init,
>>>   .fini
>>> };
>>>
>>> Same type of handlers are linked together. We first define an enum to
>>> list all types. For example:
>>>
>>> enum {
>>>   GRUB_HANDLER_INPUT,
>>>   GRUB_HANDLER_OUTPUT,
>>>   GRUB_HANDLER_CONSOLE,
>>>   GRUB_HANDLER_MENU,
>>>   GRUB_HANDLER_SCRIPT,
>>>   GRUB_HANDLER_NUM
>>> };

Seems ok to me.

Although what if we want additional handlers.  Like image readers or
so?  We do not need to centralize this.  What about this:

handler.c:

grub_handler_t
grub_handler_add (const char *name)
{
...
}

grub_err_t
grub_handler_remove (const char *name)
{
 ...
 if (module uses handler)
   return grub_error (...);
 ...
}


/* NAME is the name of the handler, HANDLER the handler struct.  */
grub_err_t
grub_handler_register (const char *name, grub_handler_t handler)
{
...
}


/* NAME is the name of the handler, HANDLER the handler struct.  */
grub_err_t
grub_handler_deregister (const char *name, grub_handler_t handler)
{
...
}


/* HANDLER the handler struct.  Hook the hook function.  */
grub_err_t
grub_handler_register (grub_handler_t handler,
   int (*hook) (grub_handler_t handler))
{
...
}


handler.h:

struct grub_handler
{
  struct grub_handler *next;
  const char *name;
};

#define GRUB_CREATE_HANDLER_H(name, interfaces) \
grub_err_t grub_##name##_register (struct grub_##name##_handler h);

(same for the other functions)

#define GRUB_CREATE_HANDLER_FUNCS(name, interfaces)  \
grub_err_t   \
grub_##name##_register (struct grub_##name##_handler h); \
{\
  grub_handler_register (name, &h->handler);
}

(same for other functions)


So the handler framework is opaque to the user.  The user just works
with this like it works now.  For example:

foo.h:

struct grub_foo
{
  /* This is *required*.  */
  grub_handler_t handle;

  /* Every FOO needs to foo.  */
  int (*foo) (int bar);
};

GRUB_CREATE_HANDLER_T ("foo", struct grub_foo);

this creates all prototypes

foo.c:

GRUB_CREATE_HANDLER ("foo", struct grub_foo);

this creates functions that are very light and are mainly there to
cast the structs back and forth so we can do type checking and get
sane warnings and maximal cleaness.  Furthermore, users can now use:

grub_foo_register (...);

^^ Every foo can register itself

grub_foo_iterate (...);

^^ You can iterate over every foo

The only "weird" thing is that when you register a handler, you have
to know its name.  For example disk.c would do:

 {
   err = grub_handler_add ("disk");
   ...
 }


So as a summary:

grub_handler_add will be used to add new handler lists,
grub_handler_remove will remove them

grub_handler_register will register specific handlers (like disk
handlers), a macro can be used to add a wrapper that passes along the
name.  grub_handler_register can fill in the mandatory member "handle"
such that later on the name is not required anymore.  Requiring
strings only at register time is not very expensive.

Sorry for the crappy code, but hopefully you get the idea, otherwise I
can hack a bit or comment on your patches :-)

>>> Then, we define an array to point to the head of handler linked list:
>>> grub_handler[GRUB

Re: [PATCH] Kernel fixes for Cygwin

[Javier Martín]

El lun, 21-07-2008 a las 13:03 -0400, Pavel Roskin escribió:
> On Mon, 2008-07-21 at 18:50 +0200, Javier Martín wrote:
> 
> > Of course, another way to go could be to allow the bootloader part of
> > GRUB to be built in PE format: it would "just" be a matter of writing
> > the PE counterparts to kern/elf.c and abstracting kern/dl.c "a
> > bit" (i.e. a lot of work). The downside to this, apart from the
> > unspecified work required, is that Windows-built i386-pc-pe modules are
> > no longer compatible with Linux-built i386-pc-elf. Not a showstopper,
> > but might require a sober thinking. As I have a lot of free time right
> > now, I'll try to think whether it's possible or not.
> 
> I think it's important to have a consistent format for modules.
I thought that two hours ago, but now I find no advantage other than the
sharing of modules between similar computers.


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Kernel fixes for Cygwin

[Pavel Roskin]

On Mon, 2008-07-21 at 18:50 +0200, Javier Martín wrote:

> Of course, another way to go could be to allow the bootloader part of
> GRUB to be built in PE format: it would "just" be a matter of writing
> the PE counterparts to kern/elf.c and abstracting kern/dl.c "a
> bit" (i.e. a lot of work). The downside to this, apart from the
> unspecified work required, is that Windows-built i386-pc-pe modules are
> no longer compatible with Linux-built i386-pc-elf. Not a showstopper,
> but might require a sober thinking. As I have a lot of free time right
> now, I'll try to think whether it's possible or not.

I think it's important to have a consistent format for modules.

> > Maybe we could treat ELF header like a multiboot header?  That means
> > that we write the header fields in the assembly language, substitute the
> > necessary variables and ask objcopy to make a raw binary that would
> > actually be an ELF file?
> As far as I understand the ELF format, this would be too complex to get
> right: there's a lot of info in there.

If ELF is too complex to write manually, we can use another format
everywhere.  It could be something GRUB specific.  But I think we should
try to use ELF, as it's widespread and extensible.

-- 
Regards,
Pavel Roskin


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Kernel fixes for Cygwin

[Javier Martín]

El lun, 21-07-2008 a las 11:51 -0400, Pavel Roskin escribió:
> On Mon, 2008-07-21 at 13:02 +0200, Javier Martín wrote:
> > El lun, 21-07-2008 a las 12:33 +0200, Christian Franke escribió:
> > > due to the complexity of PE, a stand-alone converter may likely be
> > > larger than the ~680 LoC converter I already offered here.
> > Why do we even consider a PE->ELF converter? I think the easier way to
> > go would have the people building GRUB in cygwin (not exactly newbies)
> > to have an i386-pc-elf "cross compiler" built first, then use that for
> > the bootloader programs and the normal gcc for tools. Even a "naked"
> > (i.e. libraryless) cross compiler would work, since the bootloader part
> > of GRUB is does not need libs (in C terminology, it's "freestanding").
> > That way, we are free from "objcopy bugs" or "BFD design limitations".
> 
> Well, if we want users to recompile their toolchain first, it's too much
> to ask.
I think it is not, since people building GRUB in Cygwin are not exactly
newcomers to the land of compiling: this package requires that its files
and modules be in ELF format; your compiler does not do it, so you need
another compiler. End of the problem.

Of course, another way to go could be to allow the bootloader part of
GRUB to be built in PE format: it would "just" be a matter of writing
the PE counterparts to kern/elf.c and abstracting kern/dl.c "a
bit" (i.e. a lot of work). The downside to this, apart from the
unspecified work required, is that Windows-built i386-pc-pe modules are
no longer compatible with Linux-built i386-pc-elf. Not a showstopper,
but might require a sober thinking. As I have a lot of free time right
now, I'll try to think whether it's possible or not.

> Maybe we could treat ELF header like a multiboot header?  That means
> that we write the header fields in the assembly language, substitute the
> necessary variables and ask objcopy to make a raw binary that would
> actually be an ELF file?
As far as I understand the ELF format, this would be too complex to get
right: there's a lot of info in there.
> 
> We could actually do it for all platforms, so that we won't depend on
> the object file format.
> 


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Enable writing to ATA devices, fix several bugs

[Marco Gerards]

Pavel Roskin <[EMAIL PROTECTED]> writes:

> On Mon, 2008-07-21 at 17:53 +0200, Marco Gerards wrote:
>
>> Please do not put words in my mouth, that is not what I said.  I said
>> looking at Linux *code* should be avoided.
>
> I agree with you.  I was referring to what I did, not to what you said.

Good :-)

--
Marco



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Enable writing to ATA devices, fix several bugs

[Pavel Roskin]

On Mon, 2008-07-21 at 17:53 +0200, Marco Gerards wrote:

> Please do not put words in my mouth, that is not what I said.  I said
> looking at Linux *code* should be avoided.

I agree with you.  I was referring to what I did, not to what you said.

-- 
Regards,
Pavel Roskin


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Enable writing to ATA devices, fix several bugs

[Marco Gerards]

Javier Martín <[EMAIL PROTECTED]> writes:

> El lun, 21-07-2008 a las 17:20 +0200, Marco Gerards escribió:
>> Javier Martín <[EMAIL PROTECTED]> writes:
>> 
>> > El lun, 21-07-2008 a las 14:49 +0200, Marco Gerards escribió:
>> >> Pavel Roskin <[EMAIL PROTECTED]> writes:
>> >> 
>> >> > On Sun, 2008-07-20 at 20:55 +0200, Marco Gerards wrote:
>> >> >> Pavel Roskin <[EMAIL PROTECTED]> writes:
>> >> >
>> >> >> > I know.  That's why I'll write it from specifications or maybe I'll
>> >> >> > take it from the GNU/Hurd code.
>> >> >> 
>> >> >> Taking it from Specifications will be better.
>> >> >> 
>> >> >> I think the ATA driver of GNU Mach comes from Linux 2.0 or so.  So
>> >> >> that won't change anything for us ;(.
>> >> >
>> >> > I don't think choosing consistent names could be interpreted as a
>> >> > copyright violation (except by companies like SCO, but then all bets are
>> >> > off).
>> >> 
>> >> No, you are right.  But it means that you have a look at the Linux ATA
>> >> code.  If you copy Linux names into our code, people could claim that
>> >> we looked at Linux and based our code on it.
>> > So what? Aren't both Linux and GRUB under the GPL? That _should_ mean
>> > that we can look at their code and put it into GRUB ("create a
>> > derivative work") either as-is or modified.
>> 
>> For GRUB 2 we require copyright assignments.
>>  
>> >> > Anyway, if I ever have a chance to touch the GRUB ATA code again, I'll
>> >> > use FreeBSD as a reference.  Using specification is probably not the
>> >> > best idea because we need GRUB to work on the real life hardware, and we
>> >> > need to be prepared to handle known quirks in popular hardware.
>> >> 
>> >> We were talking about not looking at copyrighted code as a
>> >> reference...  But looking at FreeBSD would be better than looking at
>> >> Linux if we want to avoid possible copyright problems.
>> > I still don't understand this: the GPL includes an irrevocable grant as
>> > long as the license is obeyed. As for copyright problems, Linux has had
>> > several clashes (SCO et al), but in each and every instance people has
>> > raised against the attacker, defended Linux and won in court. I say it
>> > "offers" quite good copyright shielding.
>> 
>> This isn't about licenses.  This is about copyright.
> I know, I know... What I'm asking is _why_ this whole obsession about
> copyright assignments. Is there a page in the wiki explaining it?

I think I explained this already and I do not want to keep repeating
everything I said several times.  There is not wiki page, but there is
a document about this for GNU maintainers:

http://www.gnu.org/prep/maintain/maintain.html#Copyright-Papers

--
Marco



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Enable writing to ATA devices, fix several bugs

[Marco Gerards]

Pavel Roskin <[EMAIL PROTECTED]> writes:

> On Mon, 2008-07-21 at 17:20 +0200, Marco Gerards wrote:
>> Javier Martín <[EMAIL PROTECTED]> writes:
>> 
>> > So what? Aren't both Linux and GRUB under the GPL? That _should_ mean
>> > that we can look at their code and put it into GRUB ("create a
>> > derivative work") either as-is or modified.
>> 
>> For GRUB 2 we require copyright assignments.
>
> Also, Linux is under GPLv2 and GRUB is under GPLv3.  This means that
> Linux developers could object that their code is restricted further than
> GPLv2 allows, e.g. there are additional anti-DRM provisions that the
> recipients of the GRUB code has to fulfill.
>
> That said, I cannot imagine that copying of variable names could be
> treated as a copyright violation.  For instance, Wine reimplements
> Windows API, and they just have to use the same names.

Please do not put words in my mouth, that is not what I said.  I said
looking at Linux *code* should be avoided.  If you have a look at the
ATA *code*, you might copy their algorithms or whatever.  I am asking
you to be careful.  Looking at code might give you an idea about how
to solve a problem, you might even implement this and legally... well,
I am not sure when you violate copyright or when not.  I cannot tell
if you looked at their code if you opened the files, study the
variable names and how they are used.

--
Marco



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Kernel fixes for Cygwin

[Pavel Roskin]

On Mon, 2008-07-21 at 13:02 +0200, Javier Martín wrote:
> El lun, 21-07-2008 a las 12:33 +0200, Christian Franke escribió:
> > due to the complexity of PE, a stand-alone converter may likely be
> > larger than the ~680 LoC converter I already offered here.
> Why do we even consider a PE->ELF converter? I think the easier way to
> go would have the people building GRUB in cygwin (not exactly newbies)
> to have an i386-pc-elf "cross compiler" built first, then use that for
> the bootloader programs and the normal gcc for tools. Even a "naked"
> (i.e. libraryless) cross compiler would work, since the bootloader part
> of GRUB is does not need libs (in C terminology, it's "freestanding").
> That way, we are free from "objcopy bugs" or "BFD design limitations".

Well, if we want users to recompile their toolchain first, it's too much
to ask.

Maybe we could treat ELF header like a multiboot header?  That means
that we write the header fields in the assembly language, substitute the
necessary variables and ask objcopy to make a raw binary that would
actually be an ELF file?

We could actually do it for all platforms, so that we won't depend on
the object file format.

-- 
Regards,
Pavel Roskin


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Enable writing to ATA devices, fix several bugs

[Pavel Roskin]

On Mon, 2008-07-21 at 17:20 +0200, Marco Gerards wrote:
> Javier Martín <[EMAIL PROTECTED]> writes:
> 
> > So what? Aren't both Linux and GRUB under the GPL? That _should_ mean
> > that we can look at their code and put it into GRUB ("create a
> > derivative work") either as-is or modified.
> 
> For GRUB 2 we require copyright assignments.

Also, Linux is under GPLv2 and GRUB is under GPLv3.  This means that
Linux developers could object that their code is restricted further than
GPLv2 allows, e.g. there are additional anti-DRM provisions that the
recipients of the GRUB code has to fulfill.

That said, I cannot imagine that copying of variable names could be
treated as a copyright violation.  For instance, Wine reimplements
Windows API, and they just have to use the same names.

-- 
Regards,
Pavel Roskin


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Enable writing to ATA devices, fix several bugs

[Javier Martín]

El lun, 21-07-2008 a las 17:20 +0200, Marco Gerards escribió:
> Javier Martín <[EMAIL PROTECTED]> writes:
> 
> > El lun, 21-07-2008 a las 14:49 +0200, Marco Gerards escribió:
> >> Pavel Roskin <[EMAIL PROTECTED]> writes:
> >> 
> >> > On Sun, 2008-07-20 at 20:55 +0200, Marco Gerards wrote:
> >> >> Pavel Roskin <[EMAIL PROTECTED]> writes:
> >> >
> >> >> > I know.  That's why I'll write it from specifications or maybe I'll
> >> >> > take it from the GNU/Hurd code.
> >> >> 
> >> >> Taking it from Specifications will be better.
> >> >> 
> >> >> I think the ATA driver of GNU Mach comes from Linux 2.0 or so.  So
> >> >> that won't change anything for us ;(.
> >> >
> >> > I don't think choosing consistent names could be interpreted as a
> >> > copyright violation (except by companies like SCO, but then all bets are
> >> > off).
> >> 
> >> No, you are right.  But it means that you have a look at the Linux ATA
> >> code.  If you copy Linux names into our code, people could claim that
> >> we looked at Linux and based our code on it.
> > So what? Aren't both Linux and GRUB under the GPL? That _should_ mean
> > that we can look at their code and put it into GRUB ("create a
> > derivative work") either as-is or modified.
> 
> For GRUB 2 we require copyright assignments.
>  
> >> > Anyway, if I ever have a chance to touch the GRUB ATA code again, I'll
> >> > use FreeBSD as a reference.  Using specification is probably not the
> >> > best idea because we need GRUB to work on the real life hardware, and we
> >> > need to be prepared to handle known quirks in popular hardware.
> >> 
> >> We were talking about not looking at copyrighted code as a
> >> reference...  But looking at FreeBSD would be better than looking at
> >> Linux if we want to avoid possible copyright problems.
> > I still don't understand this: the GPL includes an irrevocable grant as
> > long as the license is obeyed. As for copyright problems, Linux has had
> > several clashes (SCO et al), but in each and every instance people has
> > raised against the attacker, defended Linux and won in court. I say it
> > "offers" quite good copyright shielding.
> 
> This isn't about licenses.  This is about copyright.
I know, I know... What I'm asking is _why_ this whole obsession about
copyright assignments. Is there a page in the wiki explaining it?



signature.asc
Description: Esta parte del mensaje está firmada	digitalmente
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Enable writing to ATA devices, fix several bugs

[Marco Gerards]

Javier Martín <[EMAIL PROTECTED]> writes:

> El lun, 21-07-2008 a las 14:49 +0200, Marco Gerards escribió:
>> Pavel Roskin <[EMAIL PROTECTED]> writes:
>> 
>> > On Sun, 2008-07-20 at 20:55 +0200, Marco Gerards wrote:
>> >> Pavel Roskin <[EMAIL PROTECTED]> writes:
>> >
>> >> > I know.  That's why I'll write it from specifications or maybe I'll
>> >> > take it from the GNU/Hurd code.
>> >> 
>> >> Taking it from Specifications will be better.
>> >> 
>> >> I think the ATA driver of GNU Mach comes from Linux 2.0 or so.  So
>> >> that won't change anything for us ;(.
>> >
>> > I don't think choosing consistent names could be interpreted as a
>> > copyright violation (except by companies like SCO, but then all bets are
>> > off).
>> 
>> No, you are right.  But it means that you have a look at the Linux ATA
>> code.  If you copy Linux names into our code, people could claim that
>> we looked at Linux and based our code on it.
> So what? Aren't both Linux and GRUB under the GPL? That _should_ mean
> that we can look at their code and put it into GRUB ("create a
> derivative work") either as-is or modified.

For GRUB 2 we require copyright assignments.
 
>> > Anyway, if I ever have a chance to touch the GRUB ATA code again, I'll
>> > use FreeBSD as a reference.  Using specification is probably not the
>> > best idea because we need GRUB to work on the real life hardware, and we
>> > need to be prepared to handle known quirks in popular hardware.
>> 
>> We were talking about not looking at copyrighted code as a
>> reference...  But looking at FreeBSD would be better than looking at
>> Linux if we want to avoid possible copyright problems.
> I still don't understand this: the GPL includes an irrevocable grant as
> long as the license is obeyed. As for copyright problems, Linux has had
> several clashes (SCO et al), but in each and every instance people has
> raised against the attacker, defended Linux and won in court. I say it
> "offers" quite good copyright shielding.

This isn't about licenses.  This is about copyright.

--
Marco



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Strong Crypto Support for GRUB2

[Colin D Bennett]

On Mon, 21 Jul 2008 01:49:52 +0200
Simon Peter <[EMAIL PROTECTED]> wrote:

> Did the message below ever arrive on the list?
> 
> I'm still interested in getting strong crypto into grub mainline and
> while it's still not in, I just saw you guys proposed this as a
> project for Google's summer of code. Are you going to point students
> at the code I already produced? Would be a shame if you have someone
> replicate the work already done.
> 
> What's missing to get my code into GRUB2 mainline?

I think you'll have to assign copyright to the FSF.

Regards,
Colin


> Thanks!
> Simon
> 
> Begin forwarded message:
> 
> Date: Sun, 3 Feb 2008 18:25:47 +0100
> From: Simon Peter <[EMAIL PROTECTED]>
> To: The development of GRUB 2 
> Cc: Marco Gerards <[EMAIL PROTECTED]>, Robert Millan
> <[EMAIL PROTECTED]> Subject: Re: Strong Crypto Support for GRUB2
> 
> 
> > Sorry for the *very* late reply.
> 
> Sorry for my late reply. I wasn't subscribed anymore (and I'm still
> not) and only now I found out that you replied...
> 
> Attached is my patch against current CVS with the changes you proposed
> incorporated.
> 
> I'd appreciate very much if you could review this complete patch
> again. Sorry for any inconvenience with my first weird double-patch.
> 
> > > +int
> > > +aes_self_test (int verbose)
> > >  {
> [...]
> > > + printf ("passed\n");
> > Where does printf come from?
> 
> It's in a self-test routine that's actually never included in the GRUB
> source. Shall I remove the whole thing?
> 
> Thanks!
> Simon
> 
> 


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Enable writing to ATA devices, fix several bugs

[Javier Martín]

El lun, 21-07-2008 a las 14:49 +0200, Marco Gerards escribió:
> Pavel Roskin <[EMAIL PROTECTED]> writes:
> 
> > On Sun, 2008-07-20 at 20:55 +0200, Marco Gerards wrote:
> >> Pavel Roskin <[EMAIL PROTECTED]> writes:
> >
> >> > I know.  That's why I'll write it from specifications or maybe I'll
> >> > take it from the GNU/Hurd code.
> >> 
> >> Taking it from Specifications will be better.
> >> 
> >> I think the ATA driver of GNU Mach comes from Linux 2.0 or so.  So
> >> that won't change anything for us ;(.
> >
> > I don't think choosing consistent names could be interpreted as a
> > copyright violation (except by companies like SCO, but then all bets are
> > off).
> 
> No, you are right.  But it means that you have a look at the Linux ATA
> code.  If you copy Linux names into our code, people could claim that
> we looked at Linux and based our code on it.
So what? Aren't both Linux and GRUB under the GPL? That _should_ mean
that we can look at their code and put it into GRUB ("create a
derivative work") either as-is or modified.
> 
> > Anyway, if I ever have a chance to touch the GRUB ATA code again, I'll
> > use FreeBSD as a reference.  Using specification is probably not the
> > best idea because we need GRUB to work on the real life hardware, and we
> > need to be prepared to handle known quirks in popular hardware.
> 
> We were talking about not looking at copyrighted code as a
> reference...  But looking at FreeBSD would be better than looking at
> Linux if we want to avoid possible copyright problems.
I still don't understand this: the GPL includes an irrevocable grant as
long as the license is obeyed. As for copyright problems, Linux has had
several clashes (SCO et al), but in each and every instance people has
raised against the attacker, defended Linux and won in court. I say it
"offers" quite good copyright shielding.

Habbit


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Loading windows in macbook

[Bean]

Committed.

-- 
Bean


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Enable writing to ATA devices, fix several bugs

[Marco Gerards]

Pavel Roskin <[EMAIL PROTECTED]> writes:

> On Sun, 2008-07-20 at 20:55 +0200, Marco Gerards wrote:
>> Pavel Roskin <[EMAIL PROTECTED]> writes:
>
>> > I know.  That's why I'll write it from specifications or maybe I'll
>> > take it from the GNU/Hurd code.
>> 
>> Taking it from Specifications will be better.
>> 
>> I think the ATA driver of GNU Mach comes from Linux 2.0 or so.  So
>> that won't change anything for us ;(.
>
> I don't think choosing consistent names could be interpreted as a
> copyright violation (except by companies like SCO, but then all bets are
> off).

No, you are right.  But it means that you have a look at the Linux ATA
code.  If you copy Linux names into our code, people could claim that
we looked at Linux and based our code on it.

> Anyway, if I ever have a chance to touch the GRUB ATA code again, I'll
> use FreeBSD as a reference.  Using specification is probably not the
> best idea because we need GRUB to work on the real life hardware, and we
> need to be prepared to handle known quirks in popular hardware.

We were talking about not looking at copyrighted code as a
reference...  But looking at FreeBSD would be better than looking at
Linux if we want to avoid possible copyright problems.

--
Marco




___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Kernel fixes for Cygwin

[Christian Franke]

Javier Martín wrote:
> El lun, 21-07-2008 a las 12:33 +0200, Christian Franke escribió:
> > Bean wrote:
> > > BTW, if you have time, you can consider writing a tool that
> > > convert pe to elf directly, thus avoiding objcopy altogether. This
> > > shouldn't be too difficult, you can take a look at
> > > util/i386/efi/grub-mkimage.c, which does exactly the opposite,
> > > converting elf to pe32.
> > > 
> > 
> > due to the complexity of PE, a stand-alone converter may likely be
> > larger than the ~680 LoC converter I already offered here.
> Why do we even consider a PE->ELF converter? I think the easier way to
> go would have the people building GRUB in cygwin (not exactly newbies)
> to have an i386-pc-elf "cross compiler" built first, then use that for
> the bootloader programs and the normal gcc for tools. Even a "naked"
> (i.e. libraryless) cross compiler would work, since the bootloader
> part of GRUB is does not need libs (in C terminology, it's
> "freestanding").
> That way, we are free from "objcopy bugs" or "BFD design limitations".
> 

Yes, but this is not yet possible for the grub2 package in the Cygwin
distro, see:
http://lists.gnu.org/archive/html/grub-devel/2008-07/msg00263.html

Christian





___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Drivemap module

[Javier Martín]

El lun, 21-07-2008 a las 02:55 +0200, Javier Martín escribió:
> (...)
> Phew! That was long, even after removing some parts. Well, this is the
> new version of the patch. Cheers!
As always, I'm so stupid that I left the patch out... Sigh. Here it is.

Habbit
Index: commands/i386/pc/drivemap.c
===
--- commands/i386/pc/drivemap.c	(revisión: 0)
+++ commands/i386/pc/drivemap.c	(revisión: 0)
@@ -0,0 +1,393 @@
+/* drivemap.c - command to manage the BIOS drive mappings.  */
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2008  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MODNAME "drivemap"
+
+static const struct grub_arg_option options[] = {
+  {"list", 'l', 0, "show the current mappings", 0, 0},
+  {"reset", 'r', 0, "reset all mappings to the default values", 0, 0},
+  {0, 0, 0, 0, 0, 0}
+};
+
+/* Syms/vars/funcs exported from drivemap_int13h.S - start.  */
+
+/* realmode far ptr = 2 * 16b */
+extern grub_uint32_t grub_drivemap_int13_oldhandler;
+/* Size of the section to be copied */
+extern grub_uint16_t grub_drivemap_int13_size;
+
+/* NOT a typo - just need the symbol's address with &symbol.  */
+typedef void grub_symbol_t;
+extern grub_symbol_t grub_drivemap_int13_handler_base;
+extern grub_symbol_t grub_drivemap_int13_mapstart;
+
+void grub_drivemap_int13_handler (void);
+
+/* Syms/vars/funcs exported from drivemap_int13h.S - end.  */
+
+
+static grub_preboot_hookid insthandler_hook = 0;
+
+typedef struct drivemap_node
+{
+  grub_uint8_t newdrive;
+  grub_uint8_t redirto;
+  struct drivemap_node *next;
+} drivemap_node_t;
+
+static drivemap_node_t *drivemap = 0;
+static grub_err_t install_int13_handler (void);
+
+/* Puts the specified mapping into the table, replacing an existing mapping
+   for newdrive or adding a new one if required.  */
+static grub_err_t
+drivemap_set (grub_uint8_t newdrive, grub_uint8_t redirto)
+
+{
+  drivemap_node_t *mapping = 0;
+  drivemap_node_t *search = drivemap;
+  while (search)
+{
+  if (search->newdrive == newdrive)
+{
+  mapping = search;
+  break;
+}
+  search = search->next;
+}
+
+  
+  if (mapping) /* There was a mapping already in place, modify it.  */
+mapping->redirto = redirto;
+  else /* Create a new mapping and add it to the head of the list.  */
+{
+  mapping = grub_malloc (sizeof (drivemap_node_t));
+  if (!mapping)
+return grub_error (GRUB_ERR_OUT_OF_MEMORY,
+   "cannot allocate map entry, not enough memory");
+  mapping->newdrive = newdrive;
+  mapping->redirto = redirto;
+  mapping->next = drivemap;
+  drivemap = mapping;
+}
+  return GRUB_ERR_NONE;
+}
+
+/* Removes the mapping for newdrive from the table. If there is no mapping,
+   then this function behaves like a no-op on the map.  */
+static void
+drivemap_remove (grub_uint8_t newdrive)
+{
+  drivemap_node_t *mapping = 0;
+  drivemap_node_t *search = drivemap;
+  drivemap_node_t *previous = 0;
+  while (search)
+{
+  if (search->newdrive == newdrive)
+{
+  mapping = search;
+  break;
+}
+  previous = search;
+  search = search->next;
+}
+  if (mapping) /* Found.  */
+{
+  if (previous)
+previous->next = mapping->next;
+  else /* Entry was head of list.  */
+drivemap = mapping->next;
+  grub_free (mapping);
+}
+}
+
+static grub_err_t
+parse_biosdisk (const char *name, grub_uint8_t *disknum)
+{
+  if (!name) return GRUB_ERR_BAD_ARGUMENT;
+  if (*name == '(')
+name++; /* Skip the first ( in (hd0) - disk_open wants just the name.  */
+  grub_disk_t disk = grub_disk_open (name);
+  if (!disk)
+return GRUB_ERR_UNKNOWN_DEVICE;
+  else
+{
+  enum grub_disk_dev_id id = disk->dev->id;
+  if (disknum)
+*disknum = disk->id;   /* Only sound if it's a biosdisk - check later.  */
+  grub_disk_close (disk);
+  return (GRUB_DISK_DEVICE_BIOSDISK_ID != id) ?
+  GRUB_ERR_BAD_DEVICE : GRUB_ERR_NONE;
+}
+}
+
+static grub_err_t
+revparse_biosdisk(const grub_uint8_t dnum, const char **output)
+{
+  grub_err_t ret = GRUB_ERR_UNKNOWN_DEVICE;
+  auto int find (const char *name);

Re: [PATCH] Kernel fixes for Cygwin

[Javier Martín]

El lun, 21-07-2008 a las 12:33 +0200, Christian Franke escribió:
> Bean wrote:
> > BTW, if you have time, you can consider writing a tool that convert pe
> > to elf directly, thus avoiding objcopy altogether. This shouldn't be
> > too difficult, you can take a look at util/i386/efi/grub-mkimage.c,
> > which does exactly the opposite, converting elf to pe32.
> 
> due to the complexity of PE, a stand-alone converter may likely be
> larger than the ~680 LoC converter I already offered here.
Why do we even consider a PE->ELF converter? I think the easier way to
go would have the people building GRUB in cygwin (not exactly newbies)
to have an i386-pc-elf "cross compiler" built first, then use that for
the bootloader programs and the normal gcc for tools. Even a "naked"
(i.e. libraryless) cross compiler would work, since the bootloader part
of GRUB is does not need libs (in C terminology, it's "freestanding").
That way, we are free from "objcopy bugs" or "BFD design limitations".

This scheme is kinda like what's done with x86_64-pc-linux, with the
difference that in that case we use the same gcc for both "host" and
"target" by adding -m32 to the latter, but it's essentially the same
concept.

Habbit


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Kernel fixes for Cygwin

[Bean]

On Mon, Jul 21, 2008 at 6:33 PM, Christian Franke
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> due to the complexity of PE, a stand-alone converter may likely be
> larger than the ~680 LoC converter I already offered here. It was
> rejected, see this thread:
> http://lists.gnu.org/archive/html/grub-devel/2007-11/msg00174.html
>

Hi,

I can't find the source code for your converter, perhaps you can repost it ?

IMO, it's better to use our own tool, if it's not very complicated. I
learn this lesson when writing efi support for x86_64. The gnu-efi
toolchain can produce efi image, but it turns out to have some
limitation on relocation, and it's hard to fix. I end up modifying
grub-mkimage to support converting elf to pe32+. Relying on external
tool means we are at the mercy of them, it's annoying when they have
issue, as we can't expect upstream to fix it soon.

-- 
Bean


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Putting core.img anywhere

[Javier Martín]

El lun, 21-07-2008 a las 11:13 +0200, Jean-Christophe Haessig escribió:
> Le dimanche 20 juillet 2008 à 17:06 +0200, Javier Martín a écrit :
> Hi,
> 
> > This should have been fixed by the transition to LZMA as the compression
> > algorithm for PC - core.img should now be under 32K and embeddable in
> > the 32256 bytes available before the first MBR partition.
> 
> As I stated earlier my disks are not DOS-partitioned (e.g.
> pvcreate /dev/hda). I didn't want to have one useless level of the old
> DOS partition scheme since LVM already does the job (better).
Well, I can't dissent on that, but then your whole HD, from the first to
the last LBA block, is full with data that can move at LVM's whim.

> > > However, I can ensure that my /boot logical volume is not too far from
> > > the beginning of the disk, and I thought about the following algorithm :
> > How can you do so? Is there a way to force LVM to put a certain LV
> > within a particular region of a PV within the VG?
> 
> Short answer : yes. Longer answer : LVM does not (yet) gratuitously move
> LVs among PVs, LVs stay where they have been created and when you create
> a LV on an empty PV, it is normally allocated at the beginning of the
> disk in continuous extents. And yes, using pvmove you can move data
> anywhere you like.
You can move a LV to a certain PV, but apart from that there is not a
point in the LVM "specification" or "documentation" that I've seen that
can allow you to move data into _specific_ PEs _and_ keep it there:
pvmove does the former but does not guarantee they will still be there
in, say, a week: the only way I can think of would be to tie the /boot
LV to a PV near the start of the disk, but as you said, then you
wouldn't be in this dilemma.

> > Theoretically it would work, but this is heavy duty work we're talking
> > about - potentially reading the whole disk if a single file has moved
> > due to, say, a defrag.
> 
> That's why I included the random-number-chain feature. If the file is
> accidentally moved, it can still be found by the bootsector.
> Additionnally, GRUB could display a message about this to the user,
> telling him that it is in degraded mode and that he should re-run some
> utility to reindex the file.
> As for reading the entire disk, an arbitrary upper limit could be put to
> force the boot sector to fail.
First of all, LVM2 LVs don't have to keep consistency iIrc: its PEs can
be (though usually aren't) scattered all over the VG PVs, which means
that part of core.img could be in LBA blocks 300-330 but the other
fragment might be in blocks 814567-814592. In the worst case, your
system might have to read the whole disk _once per block_ in core.img,
which is about 50 blocks long. That might be a _big_ hit.

If that weren't enough, all your system would have to fit in the
already-cramped bootsector image, since you said that there is not a
single block in the HD available for embedding. In fact, do you know if
LVM leaves space in block #0 (its "superblock") for boot code like
GRUB's? If not, you can't even install GRUB, since there is no place to
install it to.

A suggestion: if you want to keep your no-partitions schema, why don't
you boot from a floppy, a CD or a USB pendrive? You would save a lot of
headaches...

> > It would work as long as the filesystem stores 512-byte blocks together.
> > However, with tail-packing features _might_ pose a problem; and
> > filesystems that altered the data in any way, like NTFS compression or
> > some kind of inline checksumming/signing would be a no-go.
> 
> Sure, but who would use NTFS for their /boot ? Most filesystems should
> work already, I think, otherwise even LILO couldn't work…
The same kind of geek* that does not partition his hard drives ;)
Besides, I was only using NTFS compression as an example: extN
filesystems also have a compression feature (though it's not very used).
Any other kind of inline addition/alteration of the data on store by the
FS (like the addition of a checksum each 128 bytes or so) or the
breakage of the assumption that _our_ blocks are still block-aligned on
the filesystem would break your system too. Nevertheless, those
assumptions, particularly the latter, usually hold, so your system is
already quite robust as things go.

Cheers!
Habbit

* I did the same once, formatting a whole disk reiserfs for a temporary
storage addition. I've also partitioned an OLD pc laptop with GPT, so
yeah, I kinda like experimenting with partitions


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Kernel fixes for Cygwin

[Christian Franke]

Bean wrote:
> 
> Hi,
> 
> BTW, if you have time, you can consider writing a tool that convert pe
> to elf directly, thus avoiding objcopy altogether. This shouldn't be
> too difficult, you can take a look at util/i386/efi/grub-mkimage.c,
> which does exactly the opposite, converting elf to pe32.
> 
> 

Hi,

due to the complexity of PE, a stand-alone converter may likely be
larger than the ~680 LoC converter I already offered here. It was
rejected, see this thread:
http://lists.gnu.org/archive/html/grub-devel/2007-11/msg00174.html

It should be possible to build a smaller tool that only fixes the
relocation info in the generated ELF. But due to the C++ redesign of
smartmontools, my open source time is somewhat limited in the moment :-)

To provide Cygwin support for the next release, I would suggest to
accept the small hack in kern/i386/dl.c for now. It is already available
it and it works. It can be removed when a tool is available. Or accept
the converter mentioned above.

Christian





___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Kernel fixes for Cygwin

[Christian Franke]

Bean wrote:
> On Mon, Jul 21, 2008 at 4:51 AM, Christian Franke
> <...> wrote:
> > This adds Cygwin support to kernel sources. It handles the issues
> > introduced by PE->ELF conversion and adds support for
> > HAVE_ASM_USCORE.
> > 
> > Christian
> > 
> > 2007-07-20  Christian Franke  <[EMAIL PROTECTED]>
> > 
> > * include/grub/dl.h: Remove .previous, gas supports this only for
> > ELF format.
> > 
> > * include/grub/symbol.h [__CYGWIN__] (#define FUNCTION/VARIABLE):
> > Remove .type, gas supports this only for ELF format.
> > 
> > * kern/dl.c (grub_dl_resolve_symbols): Add check for grub_mod_init
> > and grub_mod_fini for symbols without a type. Handle HAVE_ASM_USCORE
> > case for these symbols.
> > (grub_dl_resolve_dependencies): Add check for trailing nullbytes in
> > symbol table. This fixes an infinite loop if table is zero filled.
> > 
> > * kern/i386/dl.c [__CYGWIN__] (fix_pc_rel_relocation): New function
> > to fix bad PC relative relocation produced by objcopy.
> > [__CYGWIN__] (grub_arch_dl_relocate_symbols): Add fix of PC relative
> > relocation.
> > (grub_arch_dl_relocate_symbols): Abort on unknown relocation type.
> > 
> 
> Hi,
> 
> I'm not fond of fixing elf relocation bug in dl.c. ...
> 

Hi,

I agree that kern/i386/dl.c:fix_pc_rel_relocation() is an ugly hack and
shall be removed when a better solution is available.


> ... First of all, this
> is an objcopy bug, it may be changed in the future, ...
> 

My patch for objcopy was rejected upstream. According to binutils
mailing list, this is not an objcopy bug, but a BFD design limitation:
http://sourceware.org/ml/binutils/2007-10/msg00306.html

So I don't expect a fix before time_t wraps around ...


> ... also, it makes
> modules compiled by cygwin not compatible with those compiled by elf
> gcc.
> 

The fix_pc_rel_relocation() works also with correct ELF files, because
the (-4) fix is only applied if necessary.

Supporting Modules compiled with ELF gcc would also require to handle
the different syntax of C-Symbols (HAVE_ASM_USCORE or NOT).

Actually my first version of supported this by aliasing symbols
with/without underscore in kern/dl.c. It was tested with modules
compiled with Linux gcc loaded by kernel.img compiled with Cygwin gcc
and vice versa and all this *worked*.

But according to a comment from Robert, this is possibly useless or not
desired, see:
http://lists.gnu.org/archive/html/grub-devel/2007-11/msg00152.html

So I removed this (non?-)feature for now. Would be easy to re-add later.

Christian





___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Fw: Re: Strong Crypto Support for GRUB2

[Michael Gorven]

On Monday 21 July 2008 01:49:52 Simon Peter wrote:
> I'm still interested in getting strong crypto into grub mainline and
> while it's still not in, I just saw you guys proposed this as a project
> for Google's summer of code. Are you going to point students at the
> code I already produced? Would be a shame if you have someone replicate
> the work already done.

Hi Simon

I've been working on a LUKS module[1] for GRUB, and have used your patch as a 
starting point. I have added a few extra functions to the crypto module, and 
implemented CBC in the crypto module itself. I have also added a number of 
ciphers and hashes[2]. I am still waiting for a proper review of my patch, 
and for some license issues to be resolved. I think that my changes have 
broken the devmapper module, but I intend to implement that functionality in 
the LUKS module some time.

Michael

[1] http://lists.gnu.org/archive/html/grub-devel/2008-05/msg00127.html
[2] http://lists.gnu.org/archive/html/grub-devel/2008-05/msg00157.html

-- 
http://michael.gorven.za.net
PGP Key ID 6612FE85
S/MIME Key ID D33AEB31


signature.asc
Description: This is a digitally signed message part.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Putting core.img anywhere

[Jean-Christophe Haessig]

Le dimanche 20 juillet 2008 à 17:06 +0200, Javier Martín a écrit :
Hi,

> This should have been fixed by the transition to LZMA as the compression
> algorithm for PC - core.img should now be under 32K and embeddable in
> the 32256 bytes available before the first MBR partition.

As I stated earlier my disks are not DOS-partitioned (e.g.
pvcreate /dev/hda). I didn't want to have one useless level of the old
DOS partition scheme since LVM already does the job (better).

> > However, I can ensure that my /boot logical volume is not too far from
> > the beginning of the disk, and I thought about the following algorithm :
> How can you do so? Is there a way to force LVM to put a certain LV
> within a particular region of a PV within the VG?

Short answer : yes. Longer answer : LVM does not (yet) gratuitously move
LVs among PVs, LVs stay where they have been created and when you create
a LV on an empty PV, it is normally allocated at the beginning of the
disk in continuous extents. And yes, using pvmove you can move data
anywhere you like.

> split your disk in two partitions, one small and one big; and format
> both as LVM PVs, then add them to the same VG. You can then force
> the /boot LV within the VG to lie in the small PV, but if you take the
> trouble to do this it's quite simpler to just create a non-LVM boot
> partition.

Yes, and were I in that case, I wouldn't have problems anyway.

> Theoretically it would work, but this is heavy duty work we're talking
> about - potentially reading the whole disk if a single file has moved
> due to, say, a defrag.

That's why I included the random-number-chain feature. If the file is
accidentally moved, it can still be found by the bootsector.
Additionnally, GRUB could display a message about this to the user,
telling him that it is in degraded mode and that he should re-run some
utility to reindex the file.
As for reading the entire disk, an arbitrary upper limit could be put to
force the boot sector to fail.

>  Besides, we could hit one of the several BIOS
> disk size limits, so you would have to ensure (as you said above) that
> core.img lies within the reasonable limits for your BIOS (8G? 32G?
> 128G?)

I'm confident that my /boot LV does not exceed the first 200M of the
drive.

> It would work as long as the filesystem stores 512-byte blocks together.
> However, with tail-packing features _might_ pose a problem; and
> filesystems that altered the data in any way, like NTFS compression or
> some kind of inline checksumming/signing would be a no-go.

Sure, but who would use NTFS for their /boot ? Most filesystems should
work already, I think, otherwise even LILO couldn't work…

JC



signature.asc
Description: Ceci est une partie de message	numériquement signée
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Kernel fixes for Cygwin

[Bean]

On Mon, Jul 21, 2008 at 3:02 PM, Bean <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 21, 2008 at 4:51 AM, Christian Franke
> <[EMAIL PROTECTED]> wrote:
>> This adds Cygwin support to kernel sources. It handles the issues introduced
>> by PE->ELF conversion and adds support for HAVE_ASM_USCORE.
>>
>> Christian
>>
>> 2007-07-20  Christian Franke  <[EMAIL PROTECTED]>
>>
>>* include/grub/dl.h: Remove .previous, gas supports this only
>>for ELF format.
>>
>>* include/grub/symbol.h [__CYGWIN__] (#define FUNCTION/VARIABLE):
>>Remove .type, gas supports this only for ELF format.
>>
>>* kern/dl.c (grub_dl_resolve_symbols): Add check for grub_mod_init
>>and grub_mod_fini for symbols without a type. Handle HAVE_ASM_USCORE
>>case for these symbols.
>>(grub_dl_resolve_dependencies): Add check for trailing nullbytes
>>in symbol table. This fixes an infinite loop if table is zero filled.
>>
>>* kern/i386/dl.c [__CYGWIN__] (fix_pc_rel_relocation): New function
>>to fix bad PC relative relocation produced by objcopy.
>>[__CYGWIN__] (grub_arch_dl_relocate_symbols): Add fix of PC relative
>> relocation.
>>(grub_arch_dl_relocate_symbols): Abort on unknown relocation type.
>
> Hi,
>
> I'm not fond of fixing elf relocation bug in dl.c. First of all, this
> is an objcopy bug, it may be changed in the future, also, it makes
> modules compiled by cygwin not compatible with those compiled by elf
> gcc.
>
> Perhaps you can write a small tool, which fix various bugs after using
> objcopy to generate the module file.

Hi,

BTW, if you have time, you can consider writing a tool that convert pe
to elf directly, thus avoiding objcopy altogether. This shouldn't be
too difficult, you can take a look at util/i386/efi/grub-mkimage.c,
which does exactly the opposite, converting elf to pe32.


-- 
Bean


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Kernel fixes for Cygwin

[Bean]

On Mon, Jul 21, 2008 at 4:51 AM, Christian Franke
<[EMAIL PROTECTED]> wrote:
> This adds Cygwin support to kernel sources. It handles the issues introduced
> by PE->ELF conversion and adds support for HAVE_ASM_USCORE.
>
> Christian
>
> 2007-07-20  Christian Franke  <[EMAIL PROTECTED]>
>
>* include/grub/dl.h: Remove .previous, gas supports this only
>for ELF format.
>
>* include/grub/symbol.h [__CYGWIN__] (#define FUNCTION/VARIABLE):
>Remove .type, gas supports this only for ELF format.
>
>* kern/dl.c (grub_dl_resolve_symbols): Add check for grub_mod_init
>and grub_mod_fini for symbols without a type. Handle HAVE_ASM_USCORE
>case for these symbols.
>(grub_dl_resolve_dependencies): Add check for trailing nullbytes
>in symbol table. This fixes an infinite loop if table is zero filled.
>
>* kern/i386/dl.c [__CYGWIN__] (fix_pc_rel_relocation): New function
>to fix bad PC relative relocation produced by objcopy.
>[__CYGWIN__] (grub_arch_dl_relocate_symbols): Add fix of PC relative
> relocation.
>(grub_arch_dl_relocate_symbols): Abort on unknown relocation type.

Hi,

I'm not fond of fixing elf relocation bug in dl.c. First of all, this
is an objcopy bug, it may be changed in the future, also, it makes
modules compiled by cygwin not compatible with those compiled by elf
gcc.

Perhaps you can write a small tool, which fix various bugs after using
objcopy to generate the module file.

-- 
Bean


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel