All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Riemer <sebastian.riemer@profitbricks.com>
To: Hannes Reinecke <hare@suse.de>
Cc: dm-devel <dm-devel@redhat.com>,
	Kay Sievers <kay.sievers@vrfy.org>,
	Bart Van Assche <bvanassche@acm.org>
Subject: Re: [PATCH] libmultipath/discovery: read sysfs files uncached
Date: Thu, 04 Apr 2013 11:42:28 +0200	[thread overview]
Message-ID: <515D4B04.6010203@profitbricks.com> (raw)
In-Reply-To: <515D211B.3080805@suse.de>

On 04.04.2013 08:43, Hannes Reinecke wrote:
> Hmm; this is not the only issue we have with libudev.
> _Setting_ of sysfs attributes is also a problem (I just send a patch
> to Kay for this).
> However, having to duplicate things feels like a waste; I'd rather
> have it implemented at the libudev side.
> 
> The problem with this patch is that we're bypassing the cache of
> libudev; so any _other_ application using libudev would still be
> reading the stale value.
> 
> I'd very much prefer to have a 'uncached' variant (or adding another
> argument 'force') which would force libudev to always read the
> current value but also adding it to the internal cache for the
> benefit of other applications.

Fine for me. I just wanted to point out that there is an issue. In the
long run it also makes most sense to me to improve libudev.

For early adopters this can be a workaround as libraries aren't that
easy to replace if they come from a binary distribution. The libudev is
part of systemd by now. So back-porting fixes to an older variant of
libudev from a distribution without systemd can be difficult. We already
work like a distribution but we don't want to maintain a git repo for
that stuff as well if we already need to maintain a git repo for the
multipath-tools.
For me as a kind of user in this case the mistake was to use a library
function which doesn't do the expected instead of implementing
differently and reporting the requirement to the library for future use.
If it's in the library, then the workaround can be removed.

Cheers,
Sebastian

  reply	other threads:[~2013-04-04  9:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-02 14:28 [PATCH] libmultipath/discovery: read sysfs files uncached Sebastian Riemer
2013-04-02 21:00 ` Christophe Varoqui
2013-04-04  6:43   ` Hannes Reinecke
2013-04-04  9:42     ` Sebastian Riemer [this message]
2013-04-04 10:00     ` Kay Sievers
2013-04-04 10:20       ` Hannes Reinecke
2013-04-04 10:47         ` Sebastian Riemer
2013-04-04 11:59         ` Kay Sievers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=515D4B04.6010203@profitbricks.com \
    --to=sebastian.riemer@profitbricks.com \
    --cc=bvanassche@acm.org \
    --cc=dm-devel@redhat.com \
    --cc=hare@suse.de \
    --cc=kay.sievers@vrfy.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.