xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xenproject.org, linux-input@vger.kernel.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-fbdev@vger.kernel.org
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH 1/5] xen: add "not_essential" flag to struct xenbus_driver
Date: Mon, 25 Oct 2021 11:30:30 +0200	[thread overview]
Message-ID: <06bf785a-c661-ce18-6e48-7077c5944890@suse.com> (raw)
In-Reply-To: <fe397fd6-a80e-d3f9-08d2-4f72ec739c0b@citrix.com>


[-- Attachment #1.1.1: Type: text/plain, Size: 1651 bytes --]

On 22.10.21 11:28, Andrew Cooper wrote:
> On 22/10/2021 07:47, Juergen Gross wrote:
>> When booting the xenbus driver will wait for PV devices to have
>> connected to their backends before continuing. The timeout is different
>> between essential and non-essential devices.
>>
>> Non-essential devices are identified by their nodenames directly in the
>> xenbus driver, which requires to update this list in case a new device
>> type being non-essential is added (this was missed for several types
>> in the past).
>>
>> In order to avoid this problem, add a "not_essential" flag to struct
>> xenbus_driver which can be set to "true" by the respective frontend.
>>
>> Set this flag for the frontends currently regarded to be not essential
>> (vkbs and vfb) and use it for testing in the xenbus driver.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
> 
> Wouldn't it be better to annotate essential?  That way, when new misc
> drivers come along, they don't by default block boot.

It isn't as if new drivers would "block boot". Normally the short
timeout for all drivers of 30 seconds is more than enough for all of
them.

I'm a little bit hesitant to have a kind of "white listing" essential
drivers, as there might be different views which drivers should have
that flag. Doing this the other way round is easier: in case of
disagreement such a patch just wouldn't go in, not breaking anything
in that case.

Additionally there might be out-of-tree PV drivers, which could be
hit by not being flagged to be essential. With the not_essential flag
the situation wouldn't change for such a driver.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3135 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

  reply	other threads:[~2021-10-25  9:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-22  6:47 [PATCH 0/5] xen: cleanup detection of non-essential pv devices Juergen Gross
2021-10-22  6:47 ` [PATCH 1/5] xen: add "not_essential" flag to struct xenbus_driver Juergen Gross
2021-10-22  9:28   ` Andrew Cooper
2021-10-25  9:30     ` Juergen Gross [this message]
2021-10-22  6:47 ` [PATCH 2/5] xen: flag xen_drm_front to be not essential for system boot Juergen Gross
2021-10-22  7:24   ` Oleksandr Andrushchenko
2021-10-22  6:47 ` [PATCH 3/5] xen: flag hvc_xen " Juergen Gross
2021-10-22  6:47 ` [PATCH 4/5] xen: flag pvcalls-front " Juergen Gross
2021-10-22  6:48 ` [PATCH 5/5] xen: flag xen_snd_front " Juergen Gross
2021-10-22  7:25   ` Oleksandr Andrushchenko
2021-11-07  4:43   ` kernel test robot
2021-10-22  7:24 ` [PATCH 0/5] xen: cleanup detection of non-essential pv devices Jan Beulich
2021-10-22  7:34   ` Juergen Gross
2021-11-22  8:20 ` Juergen Gross
2021-11-23 20:39   ` Boris Ostrovsky
2021-11-25 15:21   ` Boris Ostrovsky

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=06bf785a-c661-ce18-6e48-7077c5944890@suse.com \
    --to=jgross@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.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;
as well as URLs for NNTP newsgroup(s).