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: support for calling Linux syscalls directly


On Fri, Feb 1, 2013 at 12:36 AM, Rich Felker <dalias@aerifal.cx> wrote:
> On Thu, Jan 31, 2013 at 03:23:31PM -0800, H. Peter Anvin wrote:
>> On 01/31/2013 03:10 PM, Joseph S. Myers wrote:
>> > On Thu, 31 Jan 2013, Rich Felker wrote:
>> >
>> >> What I'd like to see is an honest reevaluation of the currently
>> >> missing syscall wrappers glibc doesn't provide. If there are some that
>> >> libc should provide, let's get them added. If they're really not meant
>> >> to be used except in a single application (or not at all -- deprecated
>> >> junk) then they can just be left alone.
>> >
>> > I agree with that approach - with the requirement that any new syscall
>> > wrapper added must have a prototype included in some header that glibc
>> > installs.
>>
>> I agree we should do this for things that are "glibc material".
>
> The approach I proposed was to determine what's "glibc material". I
> suspect everything that's not does not belong in a library at all. If
> the syscall is specific to a single package (like modutils), then the
> package (e.g. modutils) maintainers are going to be a lot more
> competent dealing with the kernel interface than a third party trying
> to maintain libinux.

So, below my (expanded) list of syscalls that don't have ful glibc
support, categorized with respect as to whether they should be in
glibc.

Cheers,

Michael


STRONG CANDIDATES FOR GLIBC

gettid(2)             See http://sourceware.org/bugzilla/show_bug.cgi?id=6399
ioprio_get(2)
ioprio_set(2)

POSSIBLE CANDIDATES FOR GLIBC

delete_module(2)      [calling signature changed in 2.6.x]
finit_module(2)
init_module(2)
io_cancel(2)
io_destroy(2)
io_getevents(2)
io_setup(2)
io_submit(2)
kcmp(2)
kexec_load(2)
perf_event_open(2)
tgkill(2)


ARCHITECTURE SPECIFIC, maybe candidates for glibc

kern_features(2)      [Sparc94]
s390_runtime_instr(2) [s390 specific]
spu_create(2)         [PowerPC specific]
spu_run(2)            [PowerPC specific]
subpage_prot(2)       [PowerPC specific]
utrap_install(2)      [Sparc]


INTENDED ONLY FOR LIBC / KERNEL USE
(No need to add a wrapper in glibc)

restart_syscall(2)


UNCERTAIN (some possibly only intended for libc use)

get_robust_list(2)
set_robust_list(2)
get_thread_area(2)
set_thread_area(2)
modify_ldt(2)
pivot_root(2)


NO GLIBC WRAPPER, BUT WRAPPER IN LIBNUMA

(This is an odd situation. No obvious reason why
things are done this way.)

get_mempolicy(2)
mbind(2)
migrate_pages(2)
move_pages(2)
set_mempolicy(2)


SYSCALLS WRAPPED IN A GLIBC FUNCTION
(No need to add a wrapper in glibc)

getcpu(2)             [there is sched_getcpu(3)]
mq_getsetattr(2)      [but there are suitable mq_*(3) wrappers]
rt_sigqueueinfo(2)    [there is sigqueue(3)]
rt_tgsigqueueinfo(2)  [there is pthread_sigqueue(3)]


OBSOLETE
(No need to add a wrapper in glibc)

getdents(2)           [readdir(3) is preferred]
query_module(2)       [obsolete]
readdir(2)            [readdir(3) is preferred]
sgetmask(2)           [obsolete, use sigprocmask(2) instead]
ssetmask(2)           [obsolete, use sigprocmask(2) instead]
sysctl(2)             [deprecated]
tkill(2)              [obsolete]


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