Re: devfs_make_node()
Re: devfs_make_node()
- Subject: Re: devfs_make_node()
- From: Nick Blievers <email@hidden>
- Date: Sat, 10 Nov 2007 12:35:20 +0800
Excellent, thanks Terry!
That should be good enough; I'll copy the diff to the radar.
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).
-- Terry
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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden