если в сисколе создать сокет недоступный с юзерспейса то будет ли он автоматически закрыт по завершению вызвавшего сискол процесса???

нет. если этот сокет не принадлежит task->fs,
кто ж его закроет?

уточнение:

сокет созданный socket_create() принадлежит task->fs или нет???

а если сокет создать через sys_socketcall(SYS_SOCKET) то закроется???

ещё раз спасибо

> сокет созданный socket_create() принадлежит task->fs или нет???

а что такое socket_create() ? может быть sock_create() ?

нет, не принадлежит, его нужно добавить в таблицу файлов процесса (sock_map_fd()), тогда он будет "завернут" в struct file и будет закрыт когда процесс сделает exit_fs(), т.е. при завершении.

> а если сокет создать через sys_socketcall(SYS_SOCKET) то закроется???

ну да, это ведь то же самое, что просто вызвать sys_socket().

интересно, кто-нибудь знает зачем вообще нам нужен этот sys_socketcall() ?

>> сокет созданный socket_create() принадлежит task->fs или нет???

>а что такое socket_create() ? может быть sock_create() ?

вы правы. это опечатка

>нет, не принадлежит, его нужно добавить в таблицу файлов процесса (sock_map_fd()), тогда он будет "завернут" в struct file и будет закрыт когда процесс сделает exit_fs(), т.е. при завершении.

>> а если сокет создать через sys_socketcall(SYS_SOCKET) то закроется???

>ну да, это ведь то же самое, что просто вызвать sys_socket().

>интересно, кто-нибудь знает зачем вообще нам нужен этот sys_socketcall() ?

потому что в ядре 2.4 непонятно по какой причине существует ограничение на 256 сисколов. что не даёт возможности развернуть sys_socketcall: на всех просто не хватит номеров

> потому что в ядре 2.4 непонятно по какой причине существует
> ограничение на 256 сисколов.

хм... если такое ограничение и есть - я не знаю, чем оно
вызвано. может, это с еще более ранних имен...

в 2.6 по-прежнему все через sys_socketcall.

>в 2.6 по-прежнему все через sys_socketcall.

ну а иначе священная корова обратной бинарной совместимости сдохнет не увидев следующей ветки ядер

> ну а иначе священная корова обратной бинарной совместимости
> сдохнет не увидев следующей ветки ядер

это верно :)))

но могли быть просто добавить __NR_socket etc без
удаления sys_socketcall. впрочем, смысла особого нет,
конечно.