Re: [Pcihpd-discuss] [RFC] New sysfs tree for hotplug

[Keiichiro Tokunaga]

Hi Greg,

Thanks for the comments:)

Greg KH wrote:
> > 2. Problem
> 
> There is no problem :)
> 
> >  Recent large machines have many PCI devices and some boards that
> > contain devices (e.g. CPU, memory, and/or I/O devices).  A certain PCI
> > device (PCI1) might be connected with other one (PCI2), which means that
> > there is a dependency between PCI1 and PCI2.
> 
> You have this today?  On what platform?  This is the first I have heard
> of this.  If needed, we can merely change the pci hotplug core to allow
> a hierarchy of pci slots.  Will that solve your problem?


I meant that a P2P bridge (that has hotpluggable slots) and a PCI device would
have such a dependency.  As you suggeted, if the PCI hotplug core is changed
that way, the dependency would be represented in sysfs quite well:)  However,
a board that contains CPU, memory and/or I/O devices still doesn't have a
directory in sysfs to represent dependencies... Actually, I'm focusing on hotplug
features for that kind of the boards, and making a patch that enables it. That
patch will be coming out soom.

 
> > 3. Suggestion
> > -------------
> >  To solve the problem, I'd like to propose the following idea.
> > 
> > ["hotplug" directory]
> >    This directory is to represent a hierarchy of hotpluggable devices.
> 
> Hm, no.  What about usb, firewire, scsi and any other future bus that
> can be "hotpluggable".  The kernel doesn't treat them differently, and
> we shouldn't either.
> 
> >   "hotpluggable device" means a device that can be powered off and
> >   removed physically from the system running.  The hierarchy describes a 
> >   dependency between each device.  This directory would be placed, like:
> > 
> >       /sys/devices/hotplug
> > 
> >   Any systems that enable hotplug (e.g. ACPI, DLPAR) can create their
> >   own directory right under the "hotplug" directory, like:
> > 
> >       /sys/devices/hotplug/acpi
> >       /sys/devices/hotplug/dlpar
> > 
> >   Each of systems can create directories and files under the own directory,
> >   and these directories should be easy for user to use.
> > 
> > 
> > [ACPI based Hotplug Case]
> >    I think that ACPI is one of the systems tha know dependencies of devices.
> 
> But it doesn't know about all devices in the system (like USB, firewire
> and others), so this would quickly break down.  I also don't like
> creating a solution that is so hard-wired for one firmware type like
> ACPI.  What about Open Firmware based machines?  Pure BIOS machines?  No
> firmware at all machines?  The current sysfs trees work just fine for
> all of them, without users having to figure out what the access type the
> kernel uses to get to the devices.


That's right.  /sys/devices/hotplug/ACPI/ tree becomes hard-wired one.  I was
thinking to define the board by using ACPI (as a "generic container device" in
ACPI namespace).  Therefore, if there is the new tree I proposed in the kernel,
it would be easy to represent the hierarchy, and a directory for the board
appears in the new tree.  So I thought that we could put an control file to
invoke the board hotplug and an information file under the directory.
(Actually, I've made a rough patch for the new tree and it seems to work fine:)
I also thought that interface for hotplug could be unified so that it would become
easier for user to use.

However, it's a hard-wired way and the current sysfs trees work fine for all of
devices as you mentioned.  Now I have just one thing necessary to sysfs.
That's a directory and files for the board.  Should I abstract the "board" and
introduce a new directory for board under /sys/devices/system/, like NUMA
node directory? (e.g. /sys/devices/system/board/)  The control file, the
information file, and etc could be created under the directory, like
/sys/devices/hotplug/board/board0/eject.  If it's possible, there might be less
impact to the kernel.  I'd appreciate it if you would comment on this :)


Thanks,
Kei
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/