Re: Sendkey patch

["Javier Martín" <lordhabbit@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1942 bytes --]

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...
> > 
> The goal is to avoid walking through list when deleting an entry from it.
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-incredibly
confusing.

Besides, I think the "user" (i.e. module) visible type returned by _add
and taken by _remove should be a "blank hidden type", i.e. you don't
need to declare "struct grub_preboot_t" in loader.h because the public
interface only uses _pointers_ to it, whose size is known. This is all
the C compiler requires and you avoid polluting the namespace with
internal implementation details. I recommend the following typedefs:

typedef struct grub_preboot_t* grub_preboot_hnd;
typedef grub_err_t *(grub_preboot_func)(int noreturn);

So that the prototypes would look

grub_preboot_hnd add(grub_preboot_func f);
void remove(grub_preboot_hnd handle);

> >> Whether we need also interface for adding "postboot" commands? (in case
> >> boot_function returns)
> > I don't think it would offer a lot of functionality because most loaders
> > don't return on failure, they just get stuck or their payload
> > triple-faults and reboots.
> 
> It's the case for i386-pc loaders but not the case of some other targets
> (e.g. EFI). So the question remains.
And same question for abortion procedures. This is a spinous matter
because clean handling is difficult, not always possible and requires
registering "undo" functions, i.e. more bloat in kernel.

-Habbit

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 827 bytes --]