RE: GRUB2 netboot development

2006-05-09 Thread Rudy Attias


Netboot is taking a different direction? I'm curious about that, can you
give some details?  

Rudy Attias


Well I followed you advice but I came across some issues, probably on
customization of the driver, I'm trying to add the tg3 to it. I made
some adjustments on the code add some here and remove some there to
resolve dependencies but one dependency I can't resolve. This function
is not in the tg3.c or tg3.h code ... :( 

I probably don't know enough C++ do understand that. If you have any
ideas I would appreciate it very much.

 

genmoddep: error: pcibios_read_config_dword in tg3 is not defined

make: *** [moddep.lst] Error 1


yes, this is right, this function is not implemented anywhere. I have
published grub2_netboot_8.tgz on my website so that you can have a look.
The module tg3.mod compiles successfully but I did not test it. By the
way, this is not c++ but c (although with a nice object oriented
design)!

I hope it will work, but if it does not, I think we should not worry too
much about that for the moment as the netboot development is taking
quite a different direction now.

Cheers!


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


Re: RE : a simple list

2006-05-09 Thread vincent guffens
Thank you for this information. Adding the concept of context is indeed
the right idea. I was doing it as follows

void function (grub_device_t dev)
{
 grub_device_t it;
 auto int look_for_dev (grub_device_t);

  int look_for_dev (grub_device_t grub_device_t other_dev)
  {
 return compare (dev, other_dev)
  }

grub_iterate_list_brk (grub_devices, look_for_dev, it);
}

but it has to be compared with something like

void function (grub_device_t dev)
{
  grub_device_t it = grub_devices;

  while (it)
  {
 if ( compare (dev, it) )
   break;
  }
}


which is obviously simpler. Maybe the only two functions that are really
needed are add and del ?

Also, I found out yesterday that
the compiler throws out warning about strict aliasing when using the
iterate function. I had to add -fno-strict-aliasing to get rid of them.



Eric Salomé wrote:
 Hi,
 
 I didn’t take a good look at current iterate functions in Grub 2, yet.
 
  
 
 Most iterations needs a “init” (before treatment of first item) and a
 “fini” (after treatment of last item).
 
 Further more, one might want to make iteration functions “re-entrant”
 (or recursive), or call-back other functions in a generic way.
 
  
 
 One way to get to such behavior easily cost a bit more than the example
 you provided : 
 
 you may just add an argument (let’s call it the context object) to the
 call of the iterate function :
 
  
 
 #define grub_iterate_list(list, func, context) \
   {typeof(list) el = list; while (el) {func(context, el); el=el-next;}
 func(context, NULL)}
 or
 
 #define grub_iterate_list(list, func) \
   {void * context = NULL; typeof(list) el = list; while (el)
 {func(context, el); el=el-next;} func(context, NULL)}
 but I prefer the first define as it allows transmission of a full
 context to the iteration function.
 
  
 
 my_struct * my_ctxt;
 
  
 
 my_ctxt = NULL; grub_iterate_list(list, my_func, my_ctxt);
 
  
 
 void my_func (my_struct ** ctxt, my_item * item) {
 
   if (item == NULL) {
 
   /* End of iteration : Do any cleanup */
 
   if (*ctxt == NULL) return;
 
   free (*ctxt) ……
 
   …..
 
   return;
 
   }
 
   if (*ctxt == NULL) {
 
/* First iteration : Do any initialization */
 
*ctxt = malloc (sizeof (my_struct)); ….
 
…..
 
 }
 
 /* Do the iteration stuff */
 
 …..
 
 return;
 
 }
 
  
 
 In grub_iterate_list_brk, you can use context to send a patern or model
 object to compare each item of the list with.
 
  
 
 The draw back is it makes iteration function a bit less readable, but a
 lot more powerful.
 
 
 
 _
 
 Eric Salomé – Paris, France
 
  
 
 -Message d'origine-
 De : [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] De la part de
 Guffens, Vincent
 Envoyé : lundi 8 mai 2006 01:14
 À : grub-devel@gnu.org
 Objet : a simple list
 
  
 
 Hi,
 
 I need to use a simple list to register the pci devices, drivers and so
 on. I notice that there are lists like that already in the code so what
 would you think about having a list.h file like that ?
 
 /* A very simple list.
  *
  * If you want a list of struct myitem
  * you do
  *
  * struct myitem *item_list;
  *
  * where myitem MUST have its next pointer as the FIRST field
  *
  * and you can then add, delete the EL item,
  * grub_add_list (item_list, el);
  * grub_del_list (item_list, el);
  *
  * or call HOOK(item) for each element of the list
  * grub_iterate_list (item_list, hook);
  *
  * This brk version will point el to the list item for which
  * HOOK(EL) returns a non-null value
  * grub_iterate_list_brk (item_list, hook, el);
  *
  */
 
 struct obj {
   struct obj *next; /* MUST BE FIRST */
 };
 
 #define grub_del_list(list, el) _grub_del_list((struct obj**) list,
 (struct obj*) el)
 #define grub_add_list(list, el) _grub_add_list((struct obj**) list,
 (struct obj*) el)
 #define grub_find_list(list, el) \
   (typeof(list)) _grub_find_list((struct obj*) list, (struct obj*) el)
 #define grub_iterate_list(list, func) \
   {typeof(list) el = list; while (el) {func(el); el=el-next;}}
 #define grub_iterate_list_brk(list, func, it) \
   {typeof(list) el = list; it = 0; \
 while (el) {if (func(el)) {it = el; break;} el=el-next; }}
 
 static inline struct obj*  _grub_find_list (struct obj *list, struct obj
 *el)
 {
   struct obj *it = list;
   for (it = list; it; it=it-next)
   {
 if (it == el) return el;
   }
   return 0;
 };
 
 static inline void _grub_add_list (struct obj **list, struct obj *el)
 {
   if ( (!el) || (_grub_find_list (*list, el)) )
 return;
  
   el-next = *list;
   *list = el;
 };
 
 static inline void _grub_del_list (struct obj **list, struct obj *el)
 {
   struct obj **p;
   struct obj *q;
 
   for (p = list, q = *p; q; p = (q-next), q = q-next)
 if (q == el)
   {
 *p = q-next;
 break;
   }
 };
 
 
 
 
 

Re: GRUB2 netboot development

2006-05-09 Thread vincent guffens
Rudy Attias wrote:
 
 Netboot is taking a different direction? I'm curious about that, can you
 give some details?  


yes, grub legacy also used the drivers from Etherboot and it was
reported not be easily manageable. When Etherboot developpers decide to
change something, the glue code written in grub might have to change too
and so grub developper must constantly track these changes. Also, this
messy glue code is not particularly elegant and is not very funny to
program. It does not seem to me that it would happen too often but it
will happen and I don't have the experience that developpers from grub
legacy have.

So now the idea is to have a unique UNDI driver or maybe to find a way
to call into etherboot and come back into grub if the PXE/UNDI is not
supported. For the moment it is not clear for anyone I think how calling
into etherboot would be done.



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


Re: Keyboard bugs

2006-05-09 Thread Yoshinori K. Okuji
On Monday 08 May 2006 09:27, Andrew Apted wrote:
 (1) in kern/i386/pc/startup.S, grub_console_checkkey()
 doesn't translate the code like getkey() does.

This is not a bug, because we don't interpret the return value as a scan code. 
As long as the return value is greater than or equal to zero, there is no 
problem.

 Personally I think the checkkey() API would be better
 as a simple boolean value.

I can agree with this, although the priority is not high.

 (2) the grub_console_getkey() and checkkey() return value
 contains junk (the scan code) in the upper byte.

 I think the return value should just be a Unicode
 character, and the GRUB_TERM_ASCII_CHAR macro should
 go away (at first I thought was a unicode chop
 function, but the real purpose is to discard the
 scan-code part).

However, we cannot say that it is a unicode char, because unicode does not 
define control codes. I bet that it is better to keep the current way, 
because this is more flexible.

Thank you for your suggestions, anyway.

Okuji


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