From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stanislav Kinsbursky Subject: [RFC] connectat() and bindat() system calls Date: Wed, 6 Jun 2012 12:38:51 +0400 Message-ID: <4FCF171B.8000207@parallels.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Cc: , , "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org" , "bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org" , James Bottomley , "devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org" To: , "davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org" Return-path: Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: netdev.vger.kernel.org Hello. I'd really appreciate for any comments on subj - implementation of new system call: connectat and bindat. Reasons for new system calls: 1) Path length for UNIX sockets is limited to 108 symbols. Syscalls are useful as is since removes limitation. 2) Ability to perform connect/bind calls to UNIX sockets starting from specified path in kernel. This is required for proper support of kernel connect operations in SUNRPC layer. Which, in turn, required for proper support of NFS in containers. These system calls could be used only for non-abstract UNIX sockets, obviously. Possible implementation could be adding of struct path pointer to sockaddr_un. But this pointer have to valid only for connect and bind calls, and caller have to hold and release path by himself. -- Best regards, Stanislav Kinsbursky