Handlers filenames and syntax versions (bug 681)

Kevin P. Fleming kpfleming at linuxfromscratch.org
Tue Oct 21 18:50:18 PDT 2003


Neven Has wrote:
>     typedef enum handler_data_e {
>         DATA_COMMAND, DATA_NAME, DATA_VERSION, DATA_FILE
>     } handler_data_e;
> 
>     typedef char *(*data_function_f)(struct element_s *, handler_data_e data);

Does this interface mean that the core still has to somehow "know" 
what to ask the handler to provide? I think I'd like to see a "flags" 
element in the handler_info structure that told the core what the 
handler is willing to provide, so that information can all be kept in 
the logical place.

I'd also like to consider moving "action" as a flag into that flags 
element, and one other item that's been on my mind: a "custom" flag. 
This would be used when someone wants to drop into (source or binary, 
doesn't matter) nALFS their own customized version of an existing 
handler (possibly just a single syntax version of that handler). When 
handlers.c is checking the new handler to see if it duplicates an 
existing one, it would allow a "custom" handler to override a 
non-custom one, but not the other way around (nor would a custom 
handler be able to override another custom handler). If someone wants 
to make a slightly-modified version of <unpack>, for example, they can 
do so by copying the source (giving it a new name, of course), setting 
the custom flag in the handler_info structure and then making their 
changes. They don't need to actually apply a patch to the existing 
sources this way. Once I have done some more work on supporting 
out-of-tree compilation, they could even just compile their custom 
handler separately and copy it into <prefix>/lib/nALFS, and bingo, 
it's used. Thoughts?

>     typedef int (*handler_function_f)(struct element_s *);
> 
>     typedef struct handler_info_s {
>         char *name;
>         char *description;
>         char *syntax_version;
>         handler_function_f main;
>         data_function_f alloc_data;
>         char **parameters;
>         int action;
>     } handler_info_s;

I like this, modulo the "flags" issue above. Any particular reason you 
like typedef-ing things like this? After working on Linux kernel stuff 
for so long I've kind of had it beaten into me that typedefs are 
evil... Certainly I don't see what they add to the mix, other than 
saving a small amount of typing.

> 
> and in handler:
> 
>     int main_ver2(element_s *el)
>     {
>         /* ... */
>     }
> 
>     char *data_ver2(element_s *el, handler_data_e data)
>     {
>         /* ... */
>     }
> 

Which will then be possible to #ifdef 
SUPPORT_SYNTAX_VERSION_2...#endif, which will be sweet :-)

>             .name = "execute",
>             .description = "Execute",

>             .name = "execute",
>             .description = "Execute",

>             .name = "execute",
>             .description = "Execute",

Even though the compiler will merge these all together, it might be 
nice from a code maintenence point of view to put them into a single 
variable and then grab pointers to that variable; at least then 
there's no worry about introducing inconsistency when you add a new 
version to the handler.

> 
> I've tested this with one handler, making necessary changes in
> handlers.c (clearing a lot of mess by having to lookup only
> handler_info).

Yes it will be much cleaner; once the conversion is done, I suspect 
the handler_s structure that is internal to nALFS can lose most of its 
members and just carry a pointer to the handler_info array element 
that came from the handler itself.

> 
> So if we agree on this, I'll do it for every handler and finally
> remove new_* files.

Thanks for the offer, that saves me some work!

Another thought: I've been thinking it would be good for there to be a 
src/handlers/template.c that contains just a skeleton handler for 
people to use when they want to create their own. If you want to put 
that into CVS once the new structures are finalized, I can modify the 
bootstrap script to ignore it so it won't get compiled.




More information about the alfs-discuss mailing list