* [RFC] eglibc / glibc and option-groups being deprecated?
@ 2013-06-18 21:00 Mark Hatle
2013-06-19 10:18 ` Phil Blundell
0 siblings, 1 reply; 2+ messages in thread
From: Mark Hatle @ 2013-06-18 21:00 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer,
openembedded-devel, Yocto Project
Recently on the eglibc mailing list there has been a discussion about removing
the option groups. See: http://www.eglibc.org/archives/patches/msg01268.html
For folks who don't know what option-groups are, it's a patch that went into
eglibc a number of years ago that allows you to disable various components
(effectively altering the API) in order to shrink the size of glibc.
It was created as an attempt to get into glibc the same type of configuration
ability that uclibc has.
In OpenEmbedded Core, it is currently being used to enable the ability to shrink
the LibC footprint to a smaller size. The Yocto Project's Poky-tiny
distribution uses it as part of the mechanism to create a smaller filesystem.
I encourage you to read the original thread, and if it affects you, please speak
up. The following is my attempt at summarizing the thread.
Currently the maintainer(s) of eglibc are working on syncing up glibc and eglibc
to the point that there will no longer be a need for eglibc. (See
http://www.eglibc.org/archives/patches/msg01261.html)
EGlibc was originally developed to house various architecture ports and other
embedded friendly features were not allowed into glibc. The majority of the
differences between eglibc and glibc have disappeared, with only a few major
exceptions. One of which is the option-groups support. This item is taking a
significant amount of resources to keep up to date, and it's unclear as to the
number of users for this functionality.
The belief of the maintainers is that the days of truly small footprint systems,
where even 1 MB of storage was a large number are coming to an end. As such,
the time and effort to maintain the option groups is likely not worth the effort.
I expect that between OpenEmbedded and the Yocto Project, a large percentage of
the users would be represented in some way. But beyond that, I don't have any
idea as to how many people actually benefit from this technology.
During the discussion the results were that either assistance with maintaining
the option-groups is needed, or the feature will be deprecated and eventually
removed. The last part of the thread it was suggested that in eglibc 2.19 it
would be deprecated, and then removed in 2.20.
--Mark
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [RFC] eglibc / glibc and option-groups being deprecated?
2013-06-18 21:00 [RFC] eglibc / glibc and option-groups being deprecated? Mark Hatle
@ 2013-06-19 10:18 ` Phil Blundell
0 siblings, 0 replies; 2+ messages in thread
From: Phil Blundell @ 2013-06-19 10:18 UTC (permalink / raw)
To: Mark Hatle; +Cc: Patches and discussions about the oe-core layer
On Tue, 2013-06-18 at 16:00 -0500, Mark Hatle wrote:
> Recently on the eglibc mailing list there has been a discussion about removing
> the option groups. See: http://www.eglibc.org/archives/patches/msg01268.html
>
> For folks who don't know what option-groups are, it's a patch that went into
> eglibc a number of years ago that allows you to disable various components
> (effectively altering the API) in order to shrink the size of glibc.
I'd be quite happy to see that functionality go away. It's never been
very obvious to me that it solves any particularly important real-world
problem, and it introduces a maintenance/complexity burden both for
eglibc itself and for its users (who can no longer rely on given
functionality being available; see our DISTRO_LIBC_FEATURES thing for
example).
p.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2013-06-19 10:18 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-06-18 21:00 [RFC] eglibc / glibc and option-groups being deprecated? Mark Hatle
2013-06-19 10:18 ` Phil Blundell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox