[haiku-development] Re: ioctl
- From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 25 Jul 2009 23:25:18 +0200
Hi Brecht,
replying here, since my mails to you keep bouncing:
Hi. This is the qmail-send program at mail.gmx.net.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<brecht@xxxxxxxxxxx>:
83.101.57.79_does_not_like_recipient./Remote_host_said:_554_5.7.1_Service_unavailable;_Client_host_[213.165.64.20]_blocked_using_dnsbl.sorbs.net;_Currently_Sending_Spam_See:_http://www.sorbs.net/lookup.shtml?213.165.64.20/Giving_up_on_83.101.57.79./
On 2009-07-25 at 15:06:50 [+0200], Brecht Machiels <brecht@xxxxxxxxxxx>
wrote:
>
> I'm slowly making some progress in the implementation of assignfs. After
> struggling a lot with understanding how the API works, I have some basic
> functionality now.
>
> Next, I would like to manage the assigns through ioctl calls, as you
> suggested. When open()ing the root node and calling ioctl on it, it
> seems that the call does not reach FS. I did remember to add my ioctl
> function (in which I print a debug message) to the fs_vnode_ops. ioctl
> sets errno to EINVAL.
>
> From ioctl documentation, I understand that it can only be called on a
> streams device. Could this be the cause? As assignfs is a virtual FS,
> there is no device, and hence I call ioctl with the root node as argument.
ioctl() can be called on any file or directory as well. The vnode's ioctl()
hook will be called. If you're using the userlandfs, you must explicitly
specify which ioctls it shall tunnel to the client FS via a kernel settings
file. Have a look at src/add-ons/kernel/file_systems/userlandfs/userlandfs.
> In ramfs, I see you set device_name[0] = '\0' in read_fs_info. Is that
> related? I currently don't have a read_fs_info for assignfs.
I don't think it's related, but you should definitely implement that hook.
Otherwise one can't even get basic information (like the flags or the root
node) on the file system. Have a look at
src/system/kernel/fs/vfs.cpp:fs_read_info() what the VFS fills in for you.
Things that don't make sense for your FS (e.g. block size) you can fill in
with dummy values.
> When I mount assignfs (not specifying a device), assignfs_mount() is
> called with device = "//". Shouldn't this be NULL?
Doesn't sound right indeed. Please file a Trac ticket for that, so that it
won't get forgotten.
> On a related note, I have implemented open(), read(), close() and
> free_cookie() only for files. BFS seems to implement these for
> directories too (except perhaps read() - I haven't checked the sources).
> Is this required? What is it used for?
Yes, that's indeed required. The open()/close() hooks are basically the
backends for the equally named POSIX functions and those are supposed to
work on directories, too. read() and write() must fail for directories,
though.
CU, Ingo
Other related posts:
