Re: devfs_make_node()
Re: devfs_make_node()
- Subject: Re: devfs_make_node()
- From: Nick Blievers <email@hidden>
- Date: Fri, 09 Nov 2007 13:02:02 +0800
Terry Lambert wrote:
On Nov 8, 2007, at 6:47 PM, Nick Blievers wrote:
Hi,
This is really an FYI more than anything. There is a bug in
dev_finddir() that affects devfs_make_node() such that if you pass it
a path that contains a directory, the directory will be created but
the name will be truncated. This stems from a simple off by one error
in dev_finddir().
Although I have raised a bug about this, I have been told that I
shouldn't be trying to create directories as part of a device name.
This problem was introduced in leopard with the shift away from
unsafe string functions. So rather than strncpy(), strlcpy() has been
used, without the appropriate length change.
I am curious what the reasons are that make it considered unsafe to
create a subdirectory under /dev -- but mainly this email is to make
people aware of a regression which exists in leopard that apparently
will not get fixed.
This is not a regression, in that it did not work previously. The
directory is not created, and if you look at defvfs_mknod(), you will
see that if the node type is VDIR, the following code triggers:
I have to disagree with this... we have been using this since 10.2 I
think. It does work. We are not creating a directory directly, it is
getting created as a by-product of the devfs_make_node() call. If you
want sample (working) code for Tiger I am happy to provide it for you. I
am not sure if we have wires crossed here or what, but if definitely is
a regression. We are not calling devvfs_mknod(). We are calling
devfs_make_node() (is this were the confusion has come about?).
if (!(vap->va_type == VBLK) && !(vap->va_type == VCHR)) {
return (EINVAL); /* only support mknod of special files */
}
It is bogus to try and create a device node using a full rather than a
relative path.
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.
You need to either not depend on directories, or you need to use the
same mechanism that fdfs uses: a uinion mount of your own FS on top.
This is highly discouraged, as you are unlikely to get the pathconf()
and fpathconf() data correct with respect to POSIX.
Thank you for giving me a reason why its bad, I'm still not really clear
why, but I can investigate this.
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.
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