This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc topic BoFs at the Cauldron
- From: Torvald Riegel <triegel at redhat dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 08 Apr 2015 12:17:50 +0200
- Subject: Re: glibc topic BoFs at the Cauldron
- Authentication-results: sourceware.org; auth=none
- References: <20150408045842 dot GO28448 at spoyarek dot pnq dot redhat dot com>
On Wed, 2015-04-08 at 10:28 +0530, Siddhesh Poyarekar wrote:
> Hi,
>
> We have had the glibc BoF at the cauldron every year and they have
> been very useful in starting conversations among us on various topics.
> However, the usual 1 hour slot was not sufficient - in 2013 we went
> well over and were lucky to have conference rooms to ourselves so as
> to not inconvenience others and in 2014 we had to break at the hour
> and take up further topics in the hallways.
>
> So to give ourselves more time to discuss various topics, how about
> proposing topic BoFs and talks? Here are things that come to mind off
> the top of my head, I'm sure others will have more ideas:
>
> 1. glibc and microbenchmarks and whole system benchmarking
>
> 2. Tunables - I intend to work on this in the coming months, so I may
> have something to present on it at the Cauldron
>
> 3. Testing and Security - topics like fuzzing, security workflows, CI,
> testing components like nss, resolv, nscd, etc.
>
> 4. glibc math - providing a way to skip the multiple precision path,
> metalibm and the possibility of incorporating it or its results in
> libm, etc.
>
> 5. malloc - lockless fast paths, ability to incorporate alternate
> allocators more easily.
>
> 6. locales/i18n
We could also have concurrency as one of the subtopics, if there is
enough interest for that. Hopefully, we'll be further along with the
changes to the concurrent code in glibc, and there would certainly be
something to report. Cancellation might be another thing we might still
have to discuss.
Looking further out, one could argue that glibc would be the best place
to implement thread pools and similar -- IOW, features to manage (host
CPU, for now) compute resources through other interfaces than
pthread_create.
> We could additionally have the generic BoF that Carlos has proposed to
> introduce these proposals and focus on things that don't fit into
> those proposals.
Given that many of the above will probably be break-out sessions for the
main track (or at least be concurrent with other sessions), it would
likely be useful to have either or both of a glibc BoF at the start of
Cauldron as well as the end; the former to give a quick overview of
changes in glibc and the detailed BoFs to the rest of the Cauldron
audience; the latter to perhaps update the rest of the audience of
outcomes of the detailed BoFs.