PSA: migrating linux-hotplug to new vger infrastructure

PSA: migrating linux-hotplug to new vger infrastructure

[Konstantin Ryabitsev]

Good day!

I plan to migrate the linux-hotplug@vger.kernel.org list to the new
infrastructure this week. We're still doing it list-by-list to make sure that
we don't run into scaling issues with the new infra.

The migration will be performed live and should not require any downtime.
There will be no changes to how anyone interacts with the list after
migration is completed, so no action is required on anyone's part.

Please let me know if you have any concerns.

Best wishes,
-K

Re: PSA: migrating linux-hotplug to new vger infrastructure

[Greg KH]

On Mon, Nov 06, 2023 at 08:21:50AM -0500, Konstantin Ryabitsev wrote:
> Good day!
> 
> I plan to migrate the linux-hotplug@vger.kernel.org list to the new
> infrastructure this week. We're still doing it list-by-list to make sure that
> we don't run into scaling issues with the new infra.
> 
> The migration will be performed live and should not require any downtime.
> There will be no changes to how anyone interacts with the list after
> migration is completed, so no action is required on anyone's part.
> 
> Please let me know if you have any concerns.

I think the list can just be deleted, there's no traffic anymore, and
"hotplug" doesn't make any sense anymore as "everything" can be
added/removed from a Linux system these days.

So can we just remove it?

thanks,

greg k-h

Re: PSA: migrating linux-hotplug to new vger infrastructure

[Konstantin Ryabitsev]

On Mon, Nov 06, 2023 at 02:33:22PM +0100, Greg KH wrote:
> > I plan to migrate the linux-hotplug@vger.kernel.org list to the new
> > infrastructure this week. We're still doing it list-by-list to make sure that
> > we don't run into scaling issues with the new infra.
> > 
> > The migration will be performed live and should not require any downtime.
> > There will be no changes to how anyone interacts with the list after
> > migration is completed, so no action is required on anyone's part.
> > 
> > Please let me know if you have any concerns.
> 
> I think the list can just be deleted, there's no traffic anymore, and
> "hotplug" doesn't make any sense anymore as "everything" can be
> added/removed from a Linux system these days.
> 
> So can we just remove it?

There seems to be legitimate traffic from last year, so I would lean towards
migrating it for now and revisiting the question of sunsetting it next year,
after the dust settles a bit.

-K

Re: PSA: migrating linux-hotplug to new vger infrastructure

[Greg KH]

On Mon, Nov 06, 2023 at 09:29:47AM -0500, Konstantin Ryabitsev wrote:
> On Mon, Nov 06, 2023 at 02:33:22PM +0100, Greg KH wrote:
> > > I plan to migrate the linux-hotplug@vger.kernel.org list to the new
> > > infrastructure this week. We're still doing it list-by-list to make sure that
> > > we don't run into scaling issues with the new infra.
> > > 
> > > The migration will be performed live and should not require any downtime.
> > > There will be no changes to how anyone interacts with the list after
> > > migration is completed, so no action is required on anyone's part.
> > > 
> > > Please let me know if you have any concerns.
> > 
> > I think the list can just be deleted, there's no traffic anymore, and
> > "hotplug" doesn't make any sense anymore as "everything" can be
> > added/removed from a Linux system these days.
> > 
> > So can we just remove it?
> 
> There seems to be legitimate traffic from last year, so I would lean towards
> migrating it for now and revisiting the question of sunsetting it next year,
> after the dust settles a bit.

Ok, fair enough, trying to make it easier :)

Re: PSA: migrating linux-hotplug to new vger infrastructure

[Eric Pilmore]

On Mon, Nov 6, 2023 at 5:44 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
>
> I think the list can just be deleted, there's no traffic anymore, and
> "hotplug" doesn't make any sense anymore as "everything" can be
> added/removed from a Linux system these days.
>
> So can we just remove it?
>
> thanks,
>
> greg k-h

Hi Greg,

I was curious about your comment regarding "everything". Is it
possible to dynamically add/remove entire I/O sub-trees on the PCIe
side? In other words, can a PCIe bridge, and all associated
sub-branches be dynamically added/removed? If so, is there special
BIOS support required for possibly reserving adequate MMIO address
space?

Thanks,
Eric

Re: PSA: migrating linux-hotplug to new vger infrastructure

[Greg KH]

On Mon, Nov 06, 2023 at 11:05:47AM -0800, Eric Pilmore wrote:
> On Mon, Nov 6, 2023 at 5:44 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> >
> > I think the list can just be deleted, there's no traffic anymore, and
> > "hotplug" doesn't make any sense anymore as "everything" can be
> > added/removed from a Linux system these days.
> >
> > So can we just remove it?
> >
> > thanks,
> >
> > greg k-h
> 
> Hi Greg,
> 
> I was curious about your comment regarding "everything". Is it
> possible to dynamically add/remove entire I/O sub-trees on the PCIe
> side?

It has for decades.  Well, PCIe isn't decades old, but this has worked
for PCI systems for decades.

> In other words, can a PCIe bridge, and all associated
> sub-branches be dynamically added/removed?

Again, yes, for a very long time.  If your hardware supports it.

> If so, is there special BIOS support required for possibly reserving
> adequate MMIO address space?

Yes.  That's what those types of systems do, this is nothing new at all,
we had this working in Linux in 2002 or so.  You need special hardware
to support this, and USB4/Thunderbolt is bringing this for more common
hardware as well.

thanks,

greg k-h

Re: PSA: migrating linux-hotplug to new vger infrastructure

[Matthew Dharm]

On Mon, Nov 6, 2023 at 11:25 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Mon, Nov 06, 2023 at 11:05:47AM -0800, Eric Pilmore wrote:
> > On Mon, Nov 6, 2023 at 5:44 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > >
> > > I think the list can just be deleted, there's no traffic anymore, and
> > > "hotplug" doesn't make any sense anymore as "everything" can be
> > > added/removed from a Linux system these days.
> > >
> > > So can we just remove it?
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > Hi Greg,
> >
> > I was curious about your comment regarding "everything". Is it
> > possible to dynamically add/remove entire I/O sub-trees on the PCIe
> > side?
>
> It has for decades.  Well, PCIe isn't decades old, but this has worked
> for PCI systems for decades.
>
> > In other words, can a PCIe bridge, and all associated
> > sub-branches be dynamically added/removed?
>
> Again, yes, for a very long time.  If your hardware supports it.
>
> > If so, is there special BIOS support required for possibly reserving
> > adequate MMIO address space?
>
> Yes.  That's what those types of systems do, this is nothing new at all,
> we had this working in Linux in 2002 or so.  You need special hardware
> to support this, and USB4/Thunderbolt is bringing this for more common
> hardware as well.

Special MMIO reservation in BIOS is not required if a device in your
PCIe tree, such as a Broadcom Gen4 or Gen5 switch device, can reserve
address space via "synthetic mode" for missing devices.

Matt


-- 
Matthew Dharm
Former Maintainer, USB Mass Storage driver for Linux

Re: PSA: migrating linux-hotplug to new vger infrastructure

[Eric Pilmore]

On Mon, Nov 6, 2023 at 12:46 PM Matthew Dharm
<mdharm-usb@one-eyed-alien.net> wrote:
>
>
> Special MMIO reservation in BIOS is not required if a device in your
> PCIe tree, such as a Broadcom Gen4 or Gen5 switch device, can reserve
> address space via "synthetic mode" for missing devices.
>
> Matt

Yes, I'm familiar with Synthetic Mode (or Synthetic Endpoints), but
that's simply creating a dummy device to fool the BIOS into
effectively putting aside some amount of MMIO space. And that works
great so long as what you want to dynamically add fits within that
reserved space. I guess I was looking for something more flexible
where I didn't need to know a priori the "size" of what I wanted to
add in. Presumably this would require some kind of rebalancing of the
address assignments within the PCIe tree/sub-tree, which in turn
likely means temporarily "suspending" I/O activity, at least across
some portion of the I/O tree, while addresses move around.

Eric

Re: PSA: migrating linux-hotplug to new vger infrastructure

[Greg KH]

On Mon, Nov 06, 2023 at 09:12:56PM -0800, Eric Pilmore wrote:
> On Mon, Nov 6, 2023 at 12:46 PM Matthew Dharm
> <mdharm-usb@one-eyed-alien.net> wrote:
> >
> >
> > Special MMIO reservation in BIOS is not required if a device in your
> > PCIe tree, such as a Broadcom Gen4 or Gen5 switch device, can reserve
> > address space via "synthetic mode" for missing devices.
> >
> > Matt
> 
> Yes, I'm familiar with Synthetic Mode (or Synthetic Endpoints), but
> that's simply creating a dummy device to fool the BIOS into
> effectively putting aside some amount of MMIO space. And that works
> great so long as what you want to dynamically add fits within that
> reserved space. I guess I was looking for something more flexible
> where I didn't need to know a priori the "size" of what I wanted to
> add in. Presumably this would require some kind of rebalancing of the
> address assignments within the PCIe tree/sub-tree, which in turn
> likely means temporarily "suspending" I/O activity, at least across
> some portion of the I/O tree, while addresses move around.

No, that is not something that Linux supports at this time.  I also
don't think that any other operating system supports it either, right?

We always said, if someone wants to support this, great, we will be glad
to review the patches for adding this type of functionality.  But until
then, we just rely on the BIOS or other types of hardware to handle this
properly for us.

thanks,

greg k-h