Bug 49844

(In reply to comment #0)
> udisks-1.94.0.
> 
> update_hints() in udiskslinuxblock.c seems to treat all mmcblk* devices as
> removable. This isn't really correct.
> 
> The OLPC XO-1.5 has a SD card (mmcblk0) which can only be accessed by
> disassembling the laptop and removing the CPU heatsink - we regard it as
> non-removable.
> 
> The OLPC XO-1.75 has eMMC storage as mmcblk0 which is soldered onto the
> motherboard like any other component - that's definitely non-removable.
> 
> 
> The kernel has a 'removable' sysfs file for each block device. At the moment,
> it does not correctly have value '0' like it should do, but we could probably
> fix the kernel to make that happen. Maybe that would then be the most reliable
> source of info for udisks when deciding if a mmcblk device is removable.

The 'removable' in sysfs for the block layer is about whether the media and the drive are separate, not whether the drive itself is easily hotpluggable.... And for SDIO-based setups, these are very much separate ... in fact you can attach non-storage devices using SDIO. So it would be wrong to change that... SDIO storage should always have 'removable' set to 0.

There are two notions of removable in udisks... the first one is MediaRemovable, see

http://udisks.freedesktop.org/docs/latest/gdbus-org.freedesktop.UDisks2.Drive.html#gdbus-property-org-freedesktop-UDisks2-Drive.MediaRemovable

which is typically equals to the sysfs removable file but overridden in some cases, see

http://cgit.freedesktop.org/udisks/tree/src/udiskslinuxdrive.c?id=1.97.0#n124

so thumb drives gets MediaRemovable=FALSE and SD (including SDIO) gets MediaRemovable=TRUE.

Then there's Removable

http://udisks.freedesktop.org/docs/latest/gdbus-org.freedesktop.UDisks2.Drive.html#gdbus-property-org-freedesktop-UDisks2-Drive.Removable

which is like MediaRemovable but also true for fixed drives on hotpluggable buses (such as SATA disks in USB enclosures). In this case SDIO is considered a hotpluggable bus.

Then there's HintSystem and HintAuto and HintIgnore which are derived in part from the properties above. The Hint* properties are exactly what is used to determine how the UI presents and treats the device. All of these can be overridden with udev rules, see http://udisks.freedesktop.org/docs/latest/udisks.8.html

I'm wondering what you're trying to achieve here... making sure block devices stemming from a particular SD card is never shown? (Also, http://git.gnome.org/browse/gvfs/tree/monitor/udisks2/what-is-shown.txt?id=1.13.0 is releavant for that)

(In reply to comment #1)
> The 'removable' in sysfs for the block layer is about whether the media and the
> drive are separate, not whether the drive itself is easily hotpluggable.... And
> for SDIO-based setups, these are very much separate

I of course meant s/separate/not separate/ ... ie. the drive and media parts are both on the physical SD card itself. Sorry for the confusion.

(In reply to comment #1)
> The 'removable' in sysfs for the block layer is about whether the media and the
> drive are separate, not whether the drive itself is easily hotpluggable.... And
> for SDIO-based setups, these are very much separate ... in fact you can attach
> non-storage devices using SDIO. So it would be wrong to change that... SDIO
> storage should always have 'removable' set to 0.

Right, I think we're in agreement. We aren't dealing with "SDIO storage" - just regular SD cards (XO-1.5) and eMMC (XO-1.75).

In both cases the drives are not hotpluggable and the media cannot be removed from the drive.

My suggestion was that maybe the kernel could expose this information, showing that the device is very different from the "normal" case where a mmcblk* device corresponds to a SD card which can be trivially ejected by the user.

> I'm wondering what you're trying to achieve here... making sure block devices
> stemming from a particular SD card is never shown? (Also,
> http://git.gnome.org/browse/gvfs/tree/monitor/udisks2/what-is-shown.txt?id=1.13.0
> is releavant for that)

Maybe there's nothing to see here, but I just saw this code which seems questionable to me.

  /* Provide easy access to _only_ the following devices
   *
   *  - anything connected via known local buses (e.g. USB or Firewire, MMC or MemoryStick)
   *  - any device with removable media
   *
   * Be careful when extending this list as we don't want to automount
   * the world when (inadvertently) connecting to a SAN.
   */
  if (drive != NULL)
    {
      const gchar *connection_bus;
      gboolean removable;
      connection_bus = udisks_drive_get_connection_bus (drive);
      removable = udisks_drive_get_media_removable (drive);
      if (removable ||
          (g_strcmp0 (connection_bus, "usb") == 0 || g_strcmp0 (connection_bus, "firewire") == 0) ||
          (g_str_has_prefix (device_file, "/dev/mmcblk") || g_str_has_prefix (device_file, "/dev/mspblk")))
        {
          hint_system = FALSE;
          hint_auto = TRUE;
        }
    }

It seems to be looking for "user drives" - i.e. things that can be trivially added and removed, which would then be automounted and provided as "easy access". And it treats all mmcblk devices like this based on their name alone.

In the case of the XO-1.75, the mmcblk device is a chip soldered onto the motherboard and is the storage device from which the system is booted. So treating it similarly to a USB disk and setting hint_system=FALSE simply based on its name seems incorrect.

(In reply to comment #3)
> (In reply to comment #1)
> > The 'removable' in sysfs for the block layer is about whether the media and the
> > drive are separate, not whether the drive itself is easily hotpluggable.... And
> > for SDIO-based setups, these are very much separate ... in fact you can attach
> > non-storage devices using SDIO. So it would be wrong to change that... SDIO
> > storage should always have 'removable' set to 0.
> 
> Right, I think we're in agreement. We aren't dealing with "SDIO storage" - just
> regular SD cards (XO-1.5) and eMMC (XO-1.75).
> 

Well, in my book, SDIO storage is stuff like mmcblk.

> In both cases the drives are not hotpluggable and the media cannot be removed
> from the drive.

And in both cases these are "SDIO storage".

> My suggestion was that maybe the kernel could expose this information, showing
> that the device is very different from the "normal" case where a mmcblk* device
> corresponds to a SD card which can be trivially ejected by the user.

Well, that would be fine. But I don't think you can overload the 'removable' file for this. And for SDIO it's already 0 anyway....

> > I'm wondering what you're trying to achieve here... making sure block devices
> > stemming from a particular SD card is never shown? (Also,
> > http://git.gnome.org/browse/gvfs/tree/monitor/udisks2/what-is-shown.txt?id=1.13.0
> > is releavant for that)
> 
> Maybe there's nothing to see here, but I just saw this code which seems
> questionable to me.
> 
>   /* Provide easy access to _only_ the following devices
>    *
>    *  - anything connected via known local buses (e.g. USB or Firewire, MMC or
> MemoryStick)
>    *  - any device with removable media
>    *
>    * Be careful when extending this list as we don't want to automount
>    * the world when (inadvertently) connecting to a SAN.
>    */
>   if (drive != NULL)
>     {
>       const gchar *connection_bus;
>       gboolean removable;
>       connection_bus = udisks_drive_get_connection_bus (drive);
>       removable = udisks_drive_get_media_removable (drive);
>       if (removable ||
>           (g_strcmp0 (connection_bus, "usb") == 0 || g_strcmp0 (connection_bus,
> "firewire") == 0) ||
>           (g_str_has_prefix (device_file, "/dev/mmcblk") || g_str_has_prefix
> (device_file, "/dev/mspblk")))
>         {
>           hint_system = FALSE;
>           hint_auto = TRUE;
>         }
>     }
> 
> It seems to be looking for "user drives" - i.e. things that can be trivially
> added and removed, which would then be automounted and provided as "easy
> access". And it treats all mmcblk devices like this based on their name alone.
> 
> In the case of the XO-1.75, the mmcblk device is a chip soldered onto the
> motherboard and is the storage device from which the system is booted. So
> treating it similarly to a USB disk and setting hint_system=FALSE simply based
> on its name seems incorrect.

Well, until we have a reliable way for the hardware to report where it's part of the system or not, tagging mmcblk devices as non-system devices is fine assumption I think ... calling it incorrect is certainly not right. Consider what would happen if we did not make this assumption... the user would be prompted for authentication every time he wanted to mount a mmcblk device (ie. the SD card reader is practically unusable).

Look at it this way: you can easily make the same arguments for USB [1] so should also make assumptions that make the computer unusable for them? Of course not.

The other thing is that you can just ship an udev rule to override UDISKS_SYSTEM, UDISKS_AUTO and UDISKS_IGNORE for the XO-1.75....

But let's step back a couple of steps because this udev rule is actually not needed ... because if the partitions on a SD card are mounted outside udisks, then there's no problem because

 a) you can't unmount these partitions via udisks
    (it requires the .filesystem-unmount-others authz which requires auth by default)

and

 b) you shouldn't be able to eject them because things are mounted
    (in fact, Drive.Eject() fails for mmcblk devices even when nothing is mounted , see [2])

[1] : and, indeed, there's consumer hardware where some internal drives are USB and we have no way of knowing this (netbooks from a couple of years ago comes to mind).

[2] : # gdbus call --system --dest org.freedesktop.UDisks2 --object-path /org/freedesktop/UDisks2/drives/SD04G_0x50261705 --method org.freedesktop.UDisks2.Drive.Eject {}
Error: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error ejecting /dev/mmcblk0: Command-line `eject "/dev/mmcblk0"' exited with non-zero exit status 1: eject: unable to eject, last error: Invalid argument

Thanks for the explanation - I guess its fine to close this then . Looks like you're using the info that is currently available in the most appropriate way.