[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aAvEqZZeoCo8XF0G@wunner.de>
Date: Fri, 25 Apr 2025 19:21:45 +0200
From: Lukas Wunner <lukas@...ner.de>
To: Pasha Tatashin <pasha.tatashin@...een.com>
Cc: Jason Gunthorpe <jgg@...dia.com>, changyuanl@...gle.com,
graf@...zon.com, rppt@...nel.org, rientjes@...gle.com,
corbet@....net, rdunlap@...radead.org,
ilpo.jarvinen@...ux.intel.com, kanie@...ux.alibaba.com,
ojeda@...nel.org, aliceryhl@...gle.com, masahiroy@...nel.org,
akpm@...ux-foundation.org, tj@...nel.org, yoann.congal@...le.fr,
mmaurer@...gle.com, roman.gushchin@...ux.dev, chenridong@...wei.com,
axboe@...nel.dk, mark.rutland@....com, jannh@...gle.com,
vincent.guittot@...aro.org, hannes@...xchg.org,
dan.j.williams@...el.com, david@...hat.com,
joel.granados@...nel.org, rostedt@...dmis.org,
anna.schumaker@...cle.com, song@...nel.org, zhangguopeng@...inos.cn,
linux@...ssschuh.net, linux-kernel@...r.kernel.org,
linux-doc@...r.kernel.org, linux-mm@...ck.org,
gregkh@...uxfoundation.org, tglx@...utronix.de, mingo@...hat.com,
bp@...en8.de, dave.hansen@...ux.intel.com, x86@...nel.org,
hpa@...or.com, rafael@...nel.org, dakr@...nel.org,
bartosz.golaszewski@...aro.org, cw00.choi@...sung.com,
myungjoo.ham@...sung.com, yesanishhere@...il.com,
Jonathan.Cameron@...wei.com, quic_zijuhu@...cinc.com,
aleksander.lobakin@...el.com, ira.weiny@...el.com,
andriy.shevchenko@...ux.intel.com, leon@...nel.org,
bhelgaas@...gle.com, wagi@...nel.org, djeffery@...hat.com,
stuart.w.hayes@...il.com, jgowans@...zon.com,
Pratyush Yadav <ptyadav@...zon.de>
Subject: Re: [RFC v1 1/3] luo: Live Update Orchestrator
On Thu, Mar 27, 2025 at 03:29:18PM -0400, Pasha Tatashin wrote:
> 3. Dependency Management: The viability of preserving a specific
> resource (file, device) will be checked when it initially requests
> participation.
> However, the actual dependencies will only be pulled and the final
> ordered list assembled during the prepare phase. This avoids the churn
> of repeatedly adding/removing dependencies as individual components
> register.
[...]
> The overall preservation sequence involve processing these handles in
> a specific order:
>
> Preserved File Descriptors (e.g., memfd, kvmfd, iommufd, vfiofd)
> Preserved Devices (ordered appropriately, leaves-to-root)
^^^^^^^^^^^^^^
Device dependencies are no longer strictly hierarchical since the
introduction of device links. However devices_kset->list already
has the correct order, so if you follow that you should be fine.
Just be careful not to assume it's always in hierarchical order.
Thanks,
Lukas
Powered by blists - more mailing lists