From: Lennart Poettering <lennart@poettering.net>
To: Richard Weinberger <richard.weinberger@gmail.com>
Cc: systemd-devel@lists.freedesktop.org,
linux-mtd@lists.infradead.org, dxld@darkboxed.org
Subject: Re: [systemd-devel] How to properly wait for udev?
Date: Wed, 29 Nov 2023 09:47:58 +0100 [thread overview]
Message-ID: <ZWb6vp7K5tx9Lx2s@gardel-login> (raw)
In-Reply-To: <CAFLxGvwJjhLEgDP73WepEbVmh9qXECaKrsarhp-hg3LMGVBn5Q@mail.gmail.com>
On Mo, 27.11.23 21:32, Richard Weinberger (richard.weinberger@gmail.com) wrote:
> On Mon, Nov 27, 2023 at 9:29 AM Lennart Poettering
> <lennart@poettering.net> wrote:
> > If they conceptually should be considered block device equivalents, we
> > might want to extend the udev logic to such UBI devices too. Patches
> > welcome.
>
> Why doesn't udev flock() every device it is probing?
> Or asked differently, why is this feature opt-in instead of opt-out?
Some software really doesn't like it if we take BSD locks on their
devices, hence we don't take it blanket everywhere. And what's more
important even: for various devices it simply isn't safe to just
willy-nilly even open them (tape drivers and things, which might start
to pull in a tape if we do). For others we might not be able to even
open thing at all with the wrong flags (for example, because they are
output only).
Bock devices have relatively well defined semantics, there it's
generally safe to do this, hence we do.
Hence, it might be safe for UBI, but for the general case it might
not be.
That said, would BSD locking even address your issue? If you devices
are exclusive access things and we first open() them and then flock()
them, then that's not atomic. So if your test cases open the devices,
then flock() them you might still get into conflict udev because it
just open()ed the device, but didn#t get to call flock() yet.
Doesn't UBI have something like O_EXCL-behaviour that grants true
exclusive access?
Lennart
--
Lennart Poettering, Berlin
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2023-11-29 8:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-25 23:39 How to properly wait for udev? Richard Weinberger
[not found] ` <CAPWNY8UFFH_O-R=mZCjkFiOTjqR0u=JC-2SAVj=vR4chDbR2ZQ@mail.gmail.com>
2023-11-26 21:53 ` [systemd-devel] " Richard Weinberger
2023-11-27 8:29 ` Lennart Poettering
2023-11-27 9:54 ` Richard Weinberger
2023-11-27 20:32 ` Richard Weinberger
2023-11-29 8:47 ` Lennart Poettering [this message]
2023-11-30 21:56 ` Richard Weinberger
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=ZWb6vp7K5tx9Lx2s@gardel-login \
--to=lennart@poettering.net \
--cc=dxld@darkboxed.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard.weinberger@gmail.com \
--cc=systemd-devel@lists.freedesktop.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox