* [RFC] connectat() and bindat() system calls
@ 2012-06-06 8:38 ` Stanislav Kinsbursky
0 siblings, 0 replies; 4+ messages in thread
From: Stanislav Kinsbursky @ 2012-06-06 8:38 UTC (permalink / raw)
To: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org
Cc: cgroups-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
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
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* [RFC] connectat() and bindat() system calls
@ 2012-06-06 8:38 ` Stanislav Kinsbursky
0 siblings, 0 replies; 4+ messages in thread
From: Stanislav Kinsbursky @ 2012-06-06 8:38 UTC (permalink / raw)
To: linux-fsdevel, davem@davemloft.net
Cc: cgroups, containers, netdev@vger.kernel.org,
linux-nfs@vger.kernel.org, Trond.Myklebust@netapp.com,
bfields@fieldses.org, James Bottomley, devel@openvz.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
^ permalink raw reply [flat|nested] 4+ messages in thread
* [RFC] connectat() and bindat() system calls
@ 2012-06-06 8:38 ` Stanislav Kinsbursky
0 siblings, 0 replies; 4+ messages in thread
From: Stanislav Kinsbursky @ 2012-06-06 8:38 UTC (permalink / raw)
To: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org
Cc: cgroups-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
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
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* [RFC] connectat() and bindat() system calls
@ 2012-06-06 8:38 Stanislav Kinsbursky
0 siblings, 0 replies; 4+ messages in thread
From: Stanislav Kinsbursky @ 2012-06-06 8:38 UTC (permalink / raw)
To: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org
Cc: linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org,
James Bottomley, bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA,
devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-06-06 8:38 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-06-06 8:38 [RFC] connectat() and bindat() system calls Stanislav Kinsbursky
2012-06-06 8:38 ` Stanislav Kinsbursky
2012-06-06 8:38 ` Stanislav Kinsbursky
-- strict thread matches above, loose matches on Subject: below --
2012-06-06 8:38 Stanislav Kinsbursky
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.