Structs, which you can change the format of, in a single point (the macro),
instead of having to go in every file where you explicitly hand coded them ☺
Also, once you add write capability, with support of custom read/write
functions (besides the trivial "%x" printf specifier), you are not far at
all as complexity.
Moreover, IMHO, a macro is MUCH more clear than:
{"boot", {(uint64_t)&boot, 0, 0}, 0, 0555, "%x",},
Also, I am not sure what the __vartab is going to do. If put them all in
one section, you still need the section marker parsing.
On Wed, Nov 25, 2015 at 11:11 AM, ron minnich <[email protected]> wrote:
>
>
> On Wed, Nov 25, 2015 at 11:05 AM Kevin Klues <[email protected]> wrote:
>
>> mmm, I see. I'm torn between the two; they seem equivalent to me.
>> Probably comes down to a matter of preference.
>>
>>
> They're basically equivalent with one major difference: my proposal fits
> in with the convention of a fixed inter-component interface based on Dev
> structs, building on our current model; as does Barrett's.
>
> I'd prefer it if we could stick to this model. I'm a bit uncomfortable
> with the (to me) complex macros of the other approach, much less the fact
> that it introduces a new special-purpose struct and interface. It widens
> the interfaces and I'd rather we not do that.
>
> Just my $.002 (discounted opinion rate applies).
>
> ron
>
> --
> You received this message because you are subscribed to the Google Groups
> "Akaros" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Akaros" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/d/optout.
