Re: [udisks] CD-ROM polling failed due to O_EXCL flag (poller.c)

On Sat, Feb 26, 2011 at 04:53:16PM +0800, PCMan wrote:
> Thanks for the suggestions.
> I made a new patch reading from /proc/self/mountinfo as suggested by you.
> In addition, no code is taken from HAL so there is no license issue now.
> Please review the patch attached to this mail.
> 
> On Sat, Feb 26, 2011 at 12:12 AM, Kay Sievers <kay.sievers <at> vrfy.org> wrote:
> > On Fri, Feb 25, 2011 at 14:47, PCMan <pcman.tw <at> gmail.com> wrote:
> >> I made a small patch against the latest udisks in git after hacking HAL daemon
> >> and it works. Please review the patch. Thanks a lot.
> >>
> >> https://bugs.freedesktop.org/attachment.cgi?id=43798&action=edit
> >
> > mtab is officially dead now, even in mount(8). Please always use

 well, it's experimental death 

> > /proc/self/mountinfo, it has the major/minor in there, which is a far
> > more reliable match than the device file name. Example is here:

 are you sure?

 [...]

> +  if (stat (device_file, &statbuf) < 0)
> +      return FALSE;
> +
> +  ret = FALSE;
> +  f = fopen ("/proc/self/mountinfo", "r");
> +  if (f)

Re: [udisks] CD-ROM polling failed due to O_EXCL flag (poller.c)

On Tue, Mar 1, 2011 at 12:55, Karel Zak <kzak <at> redhat.com> wrote:
> On Sat, Feb 26, 2011 at 04:53:16PM +0800, PCMan wrote:
>> Thanks for the suggestions.
>> I made a new patch reading from /proc/self/mountinfo as suggested by you.
>> In addition, no code is taken from HAL so there is no license issue now.
>> Please review the patch attached to this mail.
>>
>> On Sat, Feb 26, 2011 at 12:12 AM, Kay Sievers <kay.sievers <at> vrfy.org> wrote:
>> > On Fri, Feb 25, 2011 at 14:47, PCMan <pcman.tw <at> gmail.com> wrote:
>> >> I made a small patch against the latest udisks in git after hacking HAL daemon
>> >> and it works. Please review the patch. Thanks a lot.
>> >>
>> >> https://bugs.freedesktop.org/attachment.cgi?id=43798&action=edit
>> >
>> > mtab is officially dead now, even in mount(8). Please always use
>
>  well, it's experimental death 

Systemd relies on it to be finally dead. :)

>> > /proc/self/mountinfo, it has the major/minor in there, which is a far
>> > more reliable match than the device file name. Example is here:
>
>  are you sure?

Yeah, in the usual case, yes. The device that shows up for btrfs is
just random, and in most cases only one of several.

>  major/minor numbers are not reliable with btrfs (at least on
>  2.6.35.6-45.fc14.x86_64), btrfs uses some funny dev_t numbers:

Re: [udisks] CD-ROM polling failed due to O_EXCL flag (poller.c)

On Tue, Mar 01, 2011 at 01:09:56PM +0100, Kay Sievers wrote:
> Btrfs is like a network filesystem, it has no backing device.

 but for example NFS is consistent:

 $ stat --format "%d" /mnt/store/a
 41

 $ grep /mnt/store /proc/self/mountinfo
 47 20 0:41 / /mnt/store rw,relatime - nfs sr.net.home:/mnt/store rw,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.111.1,mountvers=3,mountport=37090,mountproto=udp,addr=192.168.111.1
       ^^^^

 so the stat.st_dev is the same like in mountinfo

    Karel

--

-- 
 Karel Zak  <kzak <at> redhat.com>
 http://karelzak.blogspot.com

Re: [udisks] CD-ROM polling failed due to O_EXCL flag (poller.c)

On Tue, Mar 1, 2011 at 13:33, Karel Zak <kzak <at> redhat.com> wrote:
> On Tue, Mar 01, 2011 at 01:09:56PM +0100, Kay Sievers wrote:
>> Btrfs is like a network filesystem, it has no backing device.
>
>  but for example NFS is consistent:
>
>  $ stat --format "%d" /mnt/store/a
>  41
>
>  $ grep /mnt/store /proc/self/mountinfo
>  47 20 0:41 / /mnt/store rw,relatime - nfs sr.net.home:/mnt/store rw,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.111.1,mountvers=3,mountport=37090,mountproto=udp,addr=192.168.111.1
>       ^^^^
>
>  so the stat.st_dev is the same like in mountinfo

Ah, I see what you mean. It's unrelated to the O_EXCL thing here, not
about the device <-> mount mapping, just some weirdness with btrfs?

Kay
_______________________________________________
devkit-devel mailing list
devkit-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/devkit-devel

Re: [udisks] CD-ROM polling failed due to O_EXCL flag (poller.c)

On Tue, Mar 01, 2011 at 01:44:50PM +0100, Kay Sievers wrote:
> On Tue, Mar 1, 2011 at 13:33, Karel Zak <kzak <at> redhat.com> wrote:
> > On Tue, Mar 01, 2011 at 01:09:56PM +0100, Kay Sievers wrote:
> >> Btrfs is like a network filesystem, it has no backing device.
> >
> >  but for example NFS is consistent:
> >
> >  $ stat --format "%d" /mnt/store/a
> >  41
> >
> >  $ grep /mnt/store /proc/self/mountinfo
> >  47 20 0:41 / /mnt/store rw,relatime - nfs sr.net.home:/mnt/store rw,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.111.1,mountvers=3,mountport=37090,mountproto=udp,addr=192.168.111.1
> >       ^^^^
> >
> >  so the stat.st_dev is the same like in mountinfo
> 
> Ah, I see what you mean. It's unrelated to the O_EXCL thing here, not
> about the device <-> mount mapping, just some weirdness with btrfs?

 The problem is st_rdev as well as st_dev 

 The device<->mount mapping is not so important (it was always tricky), 
 but file<->filesystem mapping is important issue. I don't see reason 
 why stat(2).st_dev is not consistent with /proc/self/mountinfo on
 btrfs.

 Real life example:

  # vim /mnt/test/a

Adding an argument to Sleeping signal

Could an argument about whether we are suspending or hibernating be
added to org.freedesktop.UPower.Sleeping?

I ask because I have noticed that g-p-m does a few things like lock the
screen and start the screen saver and notify network-manager when it
initiates a suspend or hibernation.  This used to be fine when it was in
charge of this, but now that UPower handles it, other clients can
initiate suspend or hibernate and bypass gpm starting the screen saver.
 I think that this should be fixed by having gpm perform these tasks in
response to the Sleeping signal, but it needs to know whether it is
suspend or hibernate because its behavior can be configured to differ
between the two.

Re: Adding an argument to Sleeping signal

On 7 March 2011 20:54, Phillip Susi <psusi <at> cfl.rr.com> wrote:
> Could an argument about whether we are suspending or hibernating be
> added to org.freedesktop.UPower.Sleeping?

That's probably a sane request, although it would break API.

>  I think that this should be fixed by having gpm perform these tasks in
> response to the Sleeping signal, but it needs to know whether it is
> suspend or hibernate because its behavior can be configured to differ
> between the two.

Agreed. If you could prepare a patch I would be very grateful as I'm
exceptionally busy with GNOME3 stuff.

Thanks,

Richard.
_______________________________________________
devkit-devel mailing list
devkit-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/devkit-devel

Re: Adding an argument to Sleeping signal

On 3/8/2011 6:43 AM, Richard Hughes wrote:
> On 7 March 2011 20:54, Phillip Susi <psusi <at> cfl.rr.com> wrote:
>> Could an argument about whether we are suspending or hibernating be
>> added to org.freedesktop.UPower.Sleeping?
> 
> That's probably a sane request, although it would break API.

Is there a way to do it without breaking the API?  Perhaps by defining a
2.0 interface rev that has the argument?

Re: Adding an argument to Sleeping signal

On 03/08/2011 06:43 AM, Richard Hughes wrote:
> Agreed. If you could prepare a patch I would be very grateful as I'm
> exceptionally busy with GNOME3 stuff.

Here's my first stab at it.  Seems to work, but I think I'm using a
different dbus api than the rest of the code.  It also applies the
suspend setting always since the argument indicating whether it is a
suspend or hibernate is still missing from UPowerd.

On 03/08/2011 06:43 AM, Richard Hughes wrote:
> Agreed. If you could prepare a patch I would be very grateful as I'm
> exceptionally busy with GNOME3 stuff.

Here's my first stab at it.  Seems to work, but I think I'm using a
different dbus api than the rest of the code.  It also applies the
suspend setting always since the argument indicating whether it is a
suspend or hibernate is still missing from UPowerd.

Re: [PATCH] Add override for system internal property

Hello Patrick,

(I can't help but asking: you didn't happen to play the captain in a
famous SciFi TV series, did you?  )

Patrick Stewart [2011-02-14 18:20 +0000]:
> +  if (g_udev_device_has_property (device->priv->d, "UDISKS_FORCE_SYSTEM_INTERNAL"))

This indeed come up quite a lot, and seems like a good idea. Would you
mind if we renamed that just to "UDISKS_SYSTEM_INTERNAL", to be a bit
better aligned with the other properties, and remove the rather
redundant "force"?

> +    {
> +      if (g_udev_device_get_property_as_boolean (device->priv->d, "UDISKS_FORCE_SYSTEM_INTERNAL"))
> +        {
> +          is_system_internal = TRUE;
> +        }
> +      else
> +        {
> +          is_system_internal = FALSE;
> +        }

This can just be

      is_system_internal = g_udev_device_get_property_as_boolean (device->priv->d, "UDISKS_FORCE_SYSTEM_INTERNAL");

Thanks!

Martin