On Tue, Nov 10, 2015 at 09:35:22AM +0100, Florian Margaine wrote:
>
>
> On 11/09/2015 03:12 PM, Karel Zak wrote:
> > On Mon, Nov 09, 2015 at 02:06:26PM +0100, Florian Margaine wrote:
> >> Instead of using string functions to extract the device name and reading
> >> this file, this patch uses the loop device API through ioctl to get the
> >> correct backing file.
> >
> > #define LO_NAME_SIZE 64
> >
> > struct loop_info64 {
> > ...
> > uint8_t lo_file_name[LO_NAME_SIZE];
> > };
> >
> >
> > The loopdev is based on file descriptor, the lo_file_name[] is hint
> > only and it does not have to match with the real path and the most
> > important problem is that it uses 64-bytes buffer.
> >
> > For losetup we use LOOP_GET_STATUS64 ioctl as fallback solution only.
>
> I was thinking that this kind of code could be used, can you confirm
> that this would be fine? Untested code:
>
> static int resolve_loop_device()
> {
> int ret;
> ret = fopen('/sys/...', 'r');
> if (ret == NULL)
> if (errno == ENOENT)
> return resolve_loop_device_ioctl();
> }
>
> static int __attribute__((noinline)) resolve_loop_device_ioctl()
> {
> /* use ioctl */
> }
>
> This would use the normal path most of the time, and use the fallback
> only if necessary. The 64-bytes buffer issue would be mitigated.
Yep, first try /sys/... and when unsuccessful then try ioctl.
losetup example:
https://github.com/karelzak/util-linux/blob/master/lib/loopdev.c#L686
(it's probably too complex, but the basic idea is obvious)
Maybe we need libloop.so to share all these things between various
project :-)
Karel
--
Karel Zak <[email protected]>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
