> > > > да, совсем забыл... на самом деле все еще страшнее. для нашего glibc
> > > > (собранного с хидерами от 2.6.29) нужно ядро 2.6.27 и выше. т.ч. это
> > > > 2.6.18 все еще работает просто чудом или весь юзерспейс, что там
> > > > работает, не использует (пока не использует) новые системные вызовы.
> > > 
> > > Валера, тот эффект, который ты описываешь, правильно было бы назвать
> > > glibc ABI break.  Только я этот вопрос специально проверял, и ничего
> > > подозрительного не выявил.  Так что, пожалуйста, расскажи подробности.
> > > 
> > 
> > вот пример (тот же код и в glibc)
> > http://git.altlinux.org/people/shrek/packages/?p=klibc.git;a=blob;f=usr/klibc/signalfd.c;h=1edc05d936229b5cbf5b56afc1fb2c0ddf56f458;hb=HEAD
> > __NR_signalfd4 появился в 2.6.27
> > есть еще кучка at()
> > http://git.altlinux.org/people/shrek/packages/?p=klibc.git;a=commitdiff;h=7383280c094de24c926623b3996ce651e9d812d4
> 
> klibc - это простая библиотека, которая, в отличие от glibc, не
> обеспечивает обратной совместимости.  В glibc совсем другой код,
> при желании можешь посмотреть.

реализация signalfd в klibc была мной слизана из glibc практически 1:1

> Вопрос, эти новые системные вызовы в безусловной реализации klibc
> уже где-нибудь используются?  Если да, то начиная с каких сборок?

они используются в udev >= 143

-- 
Valery V. Inozemtsev