Hi,
So, "cute" widely means "attractive". In British Isles use at least and
possibly more pronouncedly so in Hiberno-English, it further can be used
to mean "clever" (see also the references to intellect for the
definition of 'acute'). Often combined with a mild male-ish pejorative
(e.g., "hoor", "fecker", etc.), which will would tend to give the "cute"
further connotations of "under-hand", "wily" or "scheming".
I'm obviously aware of the more diminutive "cute kitten" kind of
connotations, though I wouldn't have thought those were offensive
either. However I meant it as "clever" "attractive". With a hint of
"under-hand", in a strict sense /non-negative way in terms of it working
around limitations in C - in particular in encoding information into
symbols to catch errors at compile time (something I'm using in another
change I'm working on).
It wasn't meant to be personal (except as an indirect compliment). It
genuinely wasn't meant to diminish the patch set. Even if it could be
taken that way, there was no mens rea.
Making it so different bits of the code can use their own group of
memory type definitions. Great! Ack from me! The number of groups can be
low enough - lib + 1 per daemon / at worst at the top of a few files -
that it's still easy for anyone who wants to embed the code into
non-supported-platforms to change.
My concern is going beyond groups, and having
hard-to-wrap-in-standard-C, platform dependent functionality for a much
larger number of tokens again. I'm not sure the token at each
X{{M,C}ALLOC,FREE} call site needs to be a distinct C level symbol
rather than an enum into a table to get the safety.
As for what weird platforms. The IoT stuff the guy beside me was working
on ran both directly on tiny devices (tens to hundreds of KiBs) of
memory, but also on much larger devices (PCs, Xen). He had his "own"
tiny OS (well, his modification of "TinyOS"), compiler and a stack to
abstract stuff. Kind of what's starting to be called a "Unikernel".
And there's a broader movement across academia and industry, working to
redefine aspects of computing. From redefining standard platforms
(Linux) from distinct, individually admin-ed, mutable systems into
immutable minimal containers, to unikernels, to higher-level
abstractions to isolate code from the rest of the system.
It's hard to say what platforms will look in 5 to 10 years time. I'm
not sold on unikernels at all, but the more high-level NFV type
stuff could be interesting.
So it'd be nice to try keep code "embeddable" into different platforms,
or at least be careful about adding friction. The platform could be at
various different levels, inc. another linking into another lump of code
that provides abstractions. It'd be nice to keep Quagga "re-usable" to
the future potential stuff, where it didn't harm current use too much.
Globals can add friction. So adding them, it's worth looking at the
marginal benefits. If possible, wrapping them in something so access can
be hooked, etc.
The groups add only a low number of globals, so no objection at all. The
next level, having a global symbol that needs to be initialised for each
memtype, adds a higher barrier though.
The global-per-memtype level doesn't buy too much more over the group
level, does it? It checks the memtype exists, but not that it's the
correct memtype for the object - which isn't really more than an enum
into a table does?
So, the technical mechanism of initing stuff at link-time and adding to
a global list. OK! Doing so for a lowish number of symbols, Ok!
I just get more concerned at doing so for a /large/ number of symbols by
having 2 levels. I'm just wondering if we could have just the 1 level of
the linker-inited symbols, and then the further plethora of memtypes
inited and accessed through a standard-C-env static table?
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
Never kick a man, unless he's down.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
