This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: glibc at the Toolchains microconference at LPC 2019


Hi,

Le mercredi 26 juin 2019 à 12:50 -0400, Zack Weinberg a écrit :
> On Wed, Jun 26, 2019 at 12:39 PM Dmitry V. Levin <ldv@altlinux.org> wrote:
> > On Wed, Jun 26, 2019 at 06:01:28PM +0200, Florian Weimer wrote:
> > > glibc system call wrappers are on the agenda:
> > > 
> > > <https://www.linuxplumbersconf.org/blog/2019/toolchains-microconference-accepted-into-2019-linux-plumbers-conference/>
> > > 
> > > Will anyone from the glibc community attend and can set the right
> > > expectations?
> > 
> > What are the right expectations?
> 
> Well, _I_ think glibc should provide wrappers for all Linux system
> calls, except those that cannot be used without stomping on internal
> glibc data structures (e.g. set_tid_address, set_robust_list, brk) and
> those that have been completely superseded by newer syscalls.  

I believe many more syscalls must not be exposed by glibc by being too
specific, architecture dedicated syscalls in particular.

I strongly think that syscall wrappers that cannot be implemented with
a single line of code should be avoided, as it's a sign a dedicated
library would probably be better.

Bigger wrappers should only be allowed when the provided syscall is
intended to emulate some standard and/or cross-platform API.

So, yes, you could probably say I'm on "conservative" side :)

Regards.

-- 
Yann Droneaud
OPTEYA



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]