> what other design solution do you propose rather both inodes sharing the
> i_mapping across the different inodes like I did?
>
> I found more handy to just bump the i_count of the first inode and
> referencing it from the bd_inode, rather than dynamically allocating the
> i_mapping and have a bd_mapping, but if you prefer to dynamically
> allocate the i_mapping rather than using the i_data of the fist inode we
> can change that of course. Not sure what's the mess in the patch you're
> talking about, could you elaborate?
Bumping ->i_count on inode is _not_ an option - think what it does if
you umount the first fs.
_If_ you need an inode for block_device - allocate a new one instead of
reusing the inode that had been passed to ->open().
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/