November 2007 - Darwin-kernel

Re: solisten()
by Michael Tuexen 10 Nov '07

10 Nov '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Nov 10, 2007, at 3:35 AM, Terry Lambert wrote: why does solisten() in Leopard contain if ((so->so_proto->pr_flags & PR_CONNREQUIRED) == 0) { error = EOPNOTSUPP; goto out; } This was not there in Tiger. I do understand that you can not use listen() for UDP sockets, but this should be handled in UDP specific code. But this shouldn't stop you from being able to do what you want. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Nov 9, 2007, at 1:37 PM, Michael Tuexen wrote: On Nov 9, 2007, at 9:56 PM, Michael Smith wrote: On Nov 9, 2007, at 12:13 PM, Michael Tuexen wrote: Without actually knowing why the change was made, I would point out that saying "this is a UDP thing" specifically fails to notice that the code in question basically says "if the protocol does not require connections, you cannot listen for a connection". Which is not OK for one2many style sockets for SCTP. SCTP is connection oriented but does implicit connection management for you in case of one2many style sockets. To allow connections being accepted on these sockets you need to call listen(). Actually, just the fact of having opened a socket in that case should imply a listen. We think that this would be a bad idea. If someone writes a client he might not want to handle incoming connections. The user has explicitly allow the kernel to accept incoming connections on a socket(AF_INET, SOCK_SEQPACKET, IPPROTO_SCTP) I agree that it's inappropriate for protocols which *can* have a connection, but do not require them, and would prefer a PR_CANLISTEN or something similar, since listening implies specification of a queue depth, which can be usedful. We use the backlog parameter on this kind of socket just as a flag to enable/disable accepting new SCTP associations. Is it supposed to be possible to send without a connection? If so, then the SS_ISCONNECTED check of so_state in sosendcheck(), soreceive(), etc., might end up being problematic (this would be why I'd have a preference for PR_CANLISTEN/PR_CANCONNECT vs. PR_CONNREQUIRED, to accomodate protocols wher ethat's the case). Yes, you can just call sendmsg() and if there is no association, the kernel will automatically start one. I agree, PR_CANLISTEN or so would be much better. Another alternative would be to have separate socket types for connection required vs. not sockets, though the software would then have to treat them as distinct. Well, we have this: socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP) gives you an SCTP socket which behaves pretty similar to an TCP socket, except that it is a message oriented protocol. Here PR_CONNREQUIRED is appropriate. socket(AF_INET, SOCK_SEQPACKET, IPPROTO_SCTP) gives you an SCTP socket which behaves pretty similar to an UDP socket, but you need to call listen(fd, 1) to allow the kernel to accept associations. The management of the associations is done completely by the kernel. This email sent to site_archiver(a)lists.apple.com

1 0

Re: devfs_make_node()
by Nick Blievers 10 Nov '07

10 Nov '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Thunderbird 2.0.0.0 (Macintosh/20070326) That should be good enough; I'll copy the diff to the radar. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Excellent, thanks Terry! Note that this was never intended to be supported, and will only work for very short paths, since the path component separator is not recognized (i.e. DEVMAXNAMESIZE is an overall length, not a path component length, when used this way). On Nov 8, 2007, at 9:56 PM, Nick Blievers wrote: Terry Lambert wrote: On Nov 8, 2007, at 9:02 PM, Nick Blievers wrote: Also, if you look at Leopard sources for devfs, you will see that there is a mechanism for creating directories, but there is no KPI published for it, and its use is therefore completely unsipported and subject to change; however, it does exist. Again we are not trying to create directories directly, they are created as a by-product of calling devfs_make_node() with a full path, which the comments say (when calling dev_finddir()) acts like a mkdir -p. Are you sure you are not running into the fact that we now enforce DEVMAXNAMESIZE, instead of copying off into random memory at the end of the structure? There is a limit of 32 bytes on the path length, including all component separators. If you hack and use the unpublished method, be aware that the a_dvp needs to point to the directory in which the node is being created, so you have to do it by basing it there, rather than at the root of devfs. Specifically path component separators are not recognized. devfs_make_node() is a published method... that used to allow the creation of directories within /dev. It still does provide that functionality, just truncating one of the path elements due to an off by one error. Also FWIW: This is exactly what I told you in the radar. Sort of. I really think we are talking at cross purposes here. I am not trying to do anything new and different from whats been done previously, and I am certainly not trying to make life difficult for you. Its just that, as far as I am aware, I am using a published interface that has had a behaviour change from Tiger to Leopard, due to an off by one error. Thanks for the detailed feedback, and while I will obviously look for alternate solutions (since calling devfs_make_node("/dev/fooX/bah") really sucks), I still maintain that this is a regression. Please file a radar. This was not clear from your previous radar (in which we did resolve an off-by-one error), and as long as you are not bumping into DEVMAXNAMESIZE, we would need a radar number to hang the work off of, even if we knew it was a bug. Our path length overall is very small, so we wont be hitting DEVMAXNAMESIZE. If we look at a diff between tiger and leopard code (I hope its ok for me to post this here) --- /Developer/Darwin-8.9.0/xnu-792.17.14/bsd/miscfs/devfs/devfs_tree.c 2007-04-18 09:19:56.000000000 +0800 +++ /Developer/Darwin-9.0.0/xnu-1228//bsd/miscfs/devfs/devfs_tree.c 2007-10-30 11:58:56.000000000 +0800 @@ -266,8 +292,7 @@ while (*scan != '/' && *scan) scan++; - strncpy(component, start, scan - start); - component[ scan - start ] = '\0'; + strlcpy(component, start, scan - start); if (*scan == '/') scan++; You can see the bug. For this to be correct it should look like this: strlcpy(component, start, scan - start + 1); This minor problem has changed the way devfs_make_node() works, which is what I have been trying (and failing obviously!) to say. Other places in this file where the conversion from strncpy() to strlcpy() occurred have the extra +1, so it seems this case was just overlooked. Sorry if I caused some confusion with these posts and bug reports... didn't mean to get off on the wrong foot! I have an RFE open (#5589808) as that appeared the only option after #5584196 was dup'd. Is that enough, or do you want me to raise another bug? Nick This email sent to site_archiver(a)lists.apple.com

1 0

Re: solisten()
by Terry Lambert 10 Nov '07

10 Nov '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com why does solisten() in Leopard contain if ((so->so_proto->pr_flags & PR_CONNREQUIRED) == 0) { error = EOPNOTSUPP; goto out; } This was not there in Tiger. I do understand that you can not use listen() for UDP sockets, but this should be handled in UDP specific code. But this shouldn't stop you from being able to do what you want. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Nov 9, 2007, at 1:37 PM, Michael Tuexen wrote: On Nov 9, 2007, at 9:56 PM, Michael Smith wrote: On Nov 9, 2007, at 12:13 PM, Michael Tuexen wrote: Without actually knowing why the change was made, I would point out that saying "this is a UDP thing" specifically fails to notice that the code in question basically says "if the protocol does not require connections, you cannot listen for a connection". Which is not OK for one2many style sockets for SCTP. SCTP is connection oriented but does implicit connection management for you in case of one2many style sockets. To allow connections being accepted on these sockets you need to call listen(). Actually, just the fact of having opened a socket in that case should imply a listen. I agree that it's inappropriate for protocols which *can* have a connection, but do not require them, and would prefer a PR_CANLISTEN or something similar, since listening implies specification of a queue depth, which can be usedful. Is it supposed to be possible to send without a connection? If so, then the SS_ISCONNECTED check of so_state in sosendcheck(), soreceive(), etc., might end up being problematic (this would be why I'd have a preference for PR_CANLISTEN/PR_CANCONNECT vs. PR_CONNREQUIRED, to accomodate protocols wher ethat's the case). Another alternative would be to have separate socket types for connection required vs. not sockets, though the software would then have to treat them as distinct. This email sent to site_archiver(a)lists.apple.com

1 0

Re: solisten()
by Michael Tuexen 09 Nov '07

09 Nov '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Nov 9, 2007, at 9:56 PM, Michael Smith wrote: On Nov 9, 2007, at 12:13 PM, Michael Tuexen wrote: why does solisten() in Leopard contain if ((so->so_proto->pr_flags & PR_CONNREQUIRED) == 0) { error = EOPNOTSUPP; goto out; } This was not there in Tiger. I do understand that you can not use listen() for UDP sockets, but this should be handled in UDP specific code. Which is not OK for one2many style sockets for SCTP. SCTP is connection oriented but does implicit connection management for you in case of one2many style sockets. To allow connections being accepted on these sockets you need to call listen(). That seems perfectly reasonable to me. = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Without actually knowing why the change was made, I would point out that saying "this is a UDP thing" specifically fails to notice that the code in question basically says "if the protocol does not require connections, you cannot listen for a connection". This email sent to site_archiver(a)lists.apple.com

1 0

Re: solisten()
by Michael Smith 09 Nov '07

09 Nov '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Nov 9, 2007, at 12:13 PM, Michael Tuexen wrote: why does solisten() in Leopard contain if ((so->so_proto->pr_flags & PR_CONNREQUIRED) == 0) { error = EOPNOTSUPP; goto out; } This was not there in Tiger. I do understand that you can not use listen() for UDP sockets, but this should be handled in UDP specific code. That seems perfectly reasonable to me. = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Without actually knowing why the change was made, I would point out that saying "this is a UDP thing" specifically fails to notice that the code in question basically says "if the protocol does not require connections, you cannot listen for a connection". This email sent to site_archiver(a)lists.apple.com

1 0

solisten()
by Michael Tuexen 09 Nov '07

09 Nov '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dear all, why does solisten() in Leopard contain if ((so->so_proto->pr_flags & PR_CONNREQUIRED) == 0) { error = EOPNOTSUPP; goto out; } This was not there in Tiger. I do understand that you can not use listen() for UDP sockets, but this should be handled in UDP specific code. Best regards Michael _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: devfs_make_node()
by Terry Lambert 09 Nov '07

09 Nov '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com That should be good enough; I'll copy the diff to the radar. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Note that this was never intended to be supported, and will only work for very short paths, since the path component separator is not recognized (i.e. DEVMAXNAMESIZE is an overall length, not a path component length, when used this way). On Nov 8, 2007, at 9:56 PM, Nick Blievers wrote: Terry Lambert wrote: On Nov 8, 2007, at 9:02 PM, Nick Blievers wrote: Also, if you look at Leopard sources for devfs, you will see that there is a mechanism for creating directories, but there is no KPI published for it, and its use is therefore completely unsipported and subject to change; however, it does exist. Again we are not trying to create directories directly, they are created as a by-product of calling devfs_make_node() with a full path, which the comments say (when calling dev_finddir()) acts like a mkdir -p. Are you sure you are not running into the fact that we now enforce DEVMAXNAMESIZE, instead of copying off into random memory at the end of the structure? There is a limit of 32 bytes on the path length, including all component separators. If you hack and use the unpublished method, be aware that the a_dvp needs to point to the directory in which the node is being created, so you have to do it by basing it there, rather than at the root of devfs. Specifically path component separators are not recognized. devfs_make_node() is a published method... that used to allow the creation of directories within /dev. It still does provide that functionality, just truncating one of the path elements due to an off by one error. Also FWIW: This is exactly what I told you in the radar. Sort of. I really think we are talking at cross purposes here. I am not trying to do anything new and different from whats been done previously, and I am certainly not trying to make life difficult for you. Its just that, as far as I am aware, I am using a published interface that has had a behaviour change from Tiger to Leopard, due to an off by one error. Thanks for the detailed feedback, and while I will obviously look for alternate solutions (since calling devfs_make_node("/dev/fooX/ bah") really sucks), I still maintain that this is a regression. Please file a radar. This was not clear from your previous radar (in which we did resolve an off-by-one error), and as long as you are not bumping into DEVMAXNAMESIZE, we would need a radar number to hang the work off of, even if we knew it was a bug. Our path length overall is very small, so we wont be hitting DEVMAXNAMESIZE. If we look at a diff between tiger and leopard code (I hope its ok for me to post this here) --- /Developer/Darwin-8.9.0/xnu-792.17.14/bsd/miscfs/devfs/ devfs_tree.c 2007-04-18 09:19:56.000000000 +0800 +++ /Developer/Darwin-9.0.0/xnu-1228//bsd/miscfs/devfs/ devfs_tree.c 2007-10-30 11:58:56.000000000 +0800 @@ -266,8 +292,7 @@ while (*scan != '/' && *scan) scan++; - strncpy(component, start, scan - start); - component[ scan - start ] = '\0'; + strlcpy(component, start, scan - start); if (*scan == '/') scan++; You can see the bug. For this to be correct it should look like this: strlcpy(component, start, scan - start + 1); This minor problem has changed the way devfs_make_node() works, which is what I have been trying (and failing obviously!) to say. Other places in this file where the conversion from strncpy() to strlcpy() occurred have the extra +1, so it seems this case was just overlooked. Sorry if I caused some confusion with these posts and bug reports... didn't mean to get off on the wrong foot! I have an RFE open (#5589808) as that appeared the only option after #5584196 was dup'd. Is that enough, or do you want me to raise another bug? Nick This email sent to site_archiver(a)lists.apple.com

1 0

Re: Finder & FS plug-in bug (creation, ranaming folders)
by Alexander Obuschenko 09 Nov '07

09 Nov '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: devfs_make_node()
by Nick Blievers 09 Nov '07

09 Nov '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Thunderbird 2.0.0.0 (Macintosh/20070326) Our path length overall is very small, so we wont be hitting DEVMAXNAMESIZE. - strncpy(component, start, scan - start); - component[ scan - start ] = '\0'; + strlcpy(component, start, scan - start); if (*scan == '/') scan++; You can see the bug. For this to be correct it should look like this: strlcpy(component, start, scan - start + 1); Nick _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Terry Lambert wrote: On Nov 8, 2007, at 9:02 PM, Nick Blievers wrote: Also, if you look at Leopard sources for devfs, you will see that there is a mechanism for creating directories, but there is no KPI published for it, and its use is therefore completely unsipported and subject to change; however, it does exist. Again we are not trying to create directories directly, they are created as a by-product of calling devfs_make_node() with a full path, which the comments say (when calling dev_finddir()) acts like a mkdir -p. Are you sure you are not running into the fact that we now enforce DEVMAXNAMESIZE, instead of copying off into random memory at the end of the structure? There is a limit of 32 bytes on the path length, including all component separators. If you hack and use the unpublished method, be aware that the a_dvp needs to point to the directory in which the node is being created, so you have to do it by basing it there, rather than at the root of devfs. Specifically path component separators are not recognized. devfs_make_node() is a published method... that used to allow the creation of directories within /dev. It still does provide that functionality, just truncating one of the path elements due to an off by one error. Also FWIW: This is exactly what I told you in the radar. Sort of. I really think we are talking at cross purposes here. I am not trying to do anything new and different from whats been done previously, and I am certainly not trying to make life difficult for you. Its just that, as far as I am aware, I am using a published interface that has had a behaviour change from Tiger to Leopard, due to an off by one error. Thanks for the detailed feedback, and while I will obviously look for alternate solutions (since calling devfs_make_node("/dev/fooX/bah") really sucks), I still maintain that this is a regression. Please file a radar. This was not clear from your previous radar (in which we did resolve an off-by-one error), and as long as you are not bumping into DEVMAXNAMESIZE, we would need a radar number to hang the work off of, even if we knew it was a bug. If we look at a diff between tiger and leopard code (I hope its ok for me to post this here) --- /Developer/Darwin-8.9.0/xnu-792.17.14/bsd/miscfs/devfs/devfs_tree.c 2007-04-18 09:19:56.000000000 +0800 +++ /Developer/Darwin-9.0.0/xnu-1228//bsd/miscfs/devfs/devfs_tree.c 2007-10-30 11:58:56.000000000 +0800 @@ -266,8 +292,7 @@ while (*scan != '/' && *scan) scan++; This minor problem has changed the way devfs_make_node() works, which is what I have been trying (and failing obviously!) to say. Other places in this file where the conversion from strncpy() to strlcpy() occurred have the extra +1, so it seems this case was just overlooked. Sorry if I caused some confusion with these posts and bug reports... didn't mean to get off on the wrong foot! I have an RFE open (#5589808) as that appeared the only option after #5584196 was dup'd. Is that enough, or do you want me to raise another bug? This email sent to site_archiver(a)lists.apple.com

1 0

Re: devfs_make_node()
by Terry Lambert 09 Nov '07

09 Nov '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Nov 8, 2007, at 9:02 PM, Nick Blievers wrote: Also, if you look at Leopard sources for devfs, you will see that there is a mechanism for creating directories, but there is no KPI published for it, and its use is therefore completely unsipported and subject to change; however, it does exist. Again we are not trying to create directories directly, they are created as a by-product of calling devfs_make_node() with a full path, which the comments say (when calling dev_finddir()) acts like a mkdir -p. Are you sure you are not running into the fact that we now enforce DEVMAXNAMESIZE, instead of copying off into random memory at the end of the structure? There is a limit of 32 bytes on the path length, including all component separators. If you hack and use the unpublished method, be aware that the a_dvp needs to point to the directory in which the node is being created, so you have to do it by basing it there, rather than at the root of devfs. Specifically path component separators are not recognized. devfs_make_node() is a published method... that used to allow the creation of directories within /dev. It still does provide that functionality, just truncating one of the path elements due to an off by one error. Also FWIW: This is exactly what I told you in the radar. Sort of. I really think we are talking at cross purposes here. I am not trying to do anything new and different from whats been done previously, and I am certainly not trying to make life difficult for you. Its just that, as far as I am aware, I am using a published interface that has had a behaviour change from Tiger to Leopard, due to an off by one error. Thanks for the detailed feedback, and while I will obviously look for alternate solutions (since calling devfs_make_node("/dev/fooX/ bah") really sucks), I still maintain that this is a regression. Please file a radar. This was not clear from your previous radar (in which we did resolve an off-by-one error), and as long as you are not bumping into DEVMAXNAMESIZE, we would need a radar number to hang the work off of, even if we knew it was a bug. This email sent to site_archiver(a)lists.apple.com

1 0