bdev_ioctl usage example?

[Emmanuel Blot]

Hi,

I'd like to perform a couple of ioctl requests on a block device from
a file system server - e.g. I need to retrieve the physical properties
of an MTD / flash device at mount time.

It seems I should use (from libbdev):

int bdev_ioctl(dev_t dev, unsigned long request, void *buf, endpoint_t
user_endpt);

However I'm not sure which user_endpt argument to provide here: how
should I obtain an EP from my FS server?

libbdev bdev_ioctl does not seem actually used, so I failed to find a
useful example.

Thanks,
Manu

[David van Moolenbroek]

Hey,

On Thursday, February 12, 2015 at 4:52:28 PM UTC+1, Emmanuel Blot wrote:

However I'm not sure which user_endpt argument to provide here: how
should I obtain an EP from my FS server?

For a filesystem-initiated IOCTL, there is indeed no user endpoint. In that case, pass in the value NONE. The user_endpt parameter is only used in rare cases where the IOCTL could not conceivably have been initiated by a file system server anyway. And yes, I am horribly behind with writing documentation.. :(

Regards,
David

[Emmanuel Blot]

Hi David,

> For a filesystem-initiated IOCTL, there is indeed no user endpoint. In that
> case, pass in the value NONE. The user_endpt parameter is only used in rare
> cases where the IOCTL could not conceivably have been initiated by a file
> system server anyway. And yes, I am horribly behind with writing
> documentation.. :(

Ok, thanks a lot for this clarification.

I have an additional question, looking at the Minix FS code: the
device identifier (dev_t) is used thoroughly within the
implementation, for example when looking for a cached inode
(find_inode), dev is specified and compare against the inode's i_dev
field.

I do not get how the devices could not match, as it seems there is one
instance of FS server for each mounted partition (BTW, I'm not sure if
this implementation choice is actually documented on the Minix web
site). Is this a left-over piece of code from a previous version of
Minix, or have I actually missed something here?

In order words, fs_dev and superblock are global, unique in a given
mfs instance, so why is dev_t stored within each inode?

BTW, I think the "register" compiler hints could be safely removed as
I think they are ignored by all modern compilers.

Thanks,
Manu

[David van Moolenbroek]

Hey,

On Thursday, February 12, 2015 at 5:33:37 PM UTC+1, Emmanuel Blot wrote: 

I do not get how the devices could not match, as it seems there is one
instance of FS server for each mounted partition (BTW, I'm not sure if
this implementation choice is actually documented on the Minix web
site). Is this a left-over piece of code from a previous version of
Minix, or have I actually missed something here?

That is indeed a leftover. VFS and MFS used to be a single server, FS, which had to manage multiple mounted file systems at once. After the VFS/MFS split, the code was never reworked for the new "one mounted FS per server instance" situation.

BTW, I think the "register" compiler hints could be safely removed as
I think they are ignored by all modern compilers.

Definitely. Those, too, are just leftovers from different times.

Regards,
David