This is the mail archive of the 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: PATCH: Add x32 dummy sysctl

On 5/18/2012 6:49 PM, Roland McGrath wrote:
>> In ports, the linux-generic port does have a definition of sysctl() that
>> returns -1 with ENOSYS, and includes a stub_warning().  For now this avoids
>> potential issues from older code that might try to call this API as a
>> fallback if /proc/sys isn't available (for example).
> Yet it bloats the ABI and the library, which will persist far longer than
> the current state of any particular application source code.  It's far
> better to require trivial fixes to crufty old code than to commit to
> carrying cruft in the libc ABI forever.

Yes, this is probably fair.

However, Tilera, as a chip company, is biased towards making our chips work
in as wide a range of potential customer environments as possible without
undue change.  On the flip side, if glibc as a whole decides to (say)
deprecate sysctl() in 2.16, then remove it in 2.17, that would obviously be
completely OK from our point of view.

In some circumstances Tilera has ended up taking the lead due to strong
community push: for example, being the first Linux architecture to adopt
the new Linux asm-generic syscall API.  (Missing an open() syscall, for
example, turns out to be annoying in a surprising number of places.)  But,
as a general rule, we'd rather innovate in ways that bring extra value to
our customers (high-performance I/O libraries layered on standard Linux,
for example), rather than innovate in more generic ways like being first to
remove stale APIs.

Chris Metcalf, Tilera Corp.

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