[lkml]   [2004]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Pcihpd-discuss] [RFC] New sysfs tree for hotplug
    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 :)

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:02    [W:0.027 / U:0.060 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site