linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Keiichiro Tokunaga <tokunaga.keiich@jp.fujitsu.com>
Cc: lhcs-devel@lists.sourceforge.net,
	lhms-devel@lists.sourceforge.net,
	linux-hotplug-devel@lists.sourceforge.net,
	pcihpd-discuss@lists.sourceforge.net,
	lhns-devel@lists.sourceforge.net, linux-ia64@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	acpi-largesys-devel@lists.sourceforge.net
Subject: Re: [Pcihpd-discuss] [RFC] New sysfs tree for hotplug
Date: Fri, 16 Apr 2004 22:34:36 +0000	[thread overview]
Message-ID: <20040416223436.GB21701@kroah.com> (raw)
In-Reply-To: <20040415170939.0ff62618.tokunaga.keiich@jp.fujitsu.com>

On Thu, Apr 15, 2004 at 05:09:39PM +0900, Keiichiro Tokunaga wrote:
> 
> 1. Current sysfs for hotplug
> ----------------------------
>  In 2.6, there are some sysfs files for hotplug.  For instance, PCI has that
> kind of files to control hotplug features.  PCI related sysfs entries for hotplug
> are created under /sys/bus/pci/slots/:
> 
>     /sys/bus/pci/slots/<slot#>/<files>
> 
> There are some files under <slot#> directory.  Some of them are supposed
> to expose kenrel information, the others are supposed to control hotplug.
> Recently, CPU and memory hotplug are being worked actively.  According 
> to their patch, they seem to be trying to create sysfs files under the following
> directory.
> 
>     /sys/devices/system/

That's correct, as cpus and memory are system devices, while pci slots
belong in the pci bus directory in sysfs.

> 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?

> 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.

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

  reply	other threads:[~2004-04-16 22:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-15  8:09 [RFC] New sysfs tree for hotplug Keiichiro Tokunaga
2004-04-16 22:34 ` Greg KH [this message]
2004-04-16 23:39   ` [Pcihpd-discuss] " Grant Grundler
2004-04-23 12:21     ` Keiichiro Tokunaga
2004-04-23 12:18   ` Keiichiro Tokunaga
2004-04-23 12:30     ` Matthew Wilcox
2004-04-23 12:47     ` Matthew Wilcox
2004-04-23 20:07     ` Greg KH

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=20040416223436.GB21701@kroah.com \
    --to=greg@kroah.com \
    --cc=acpi-largesys-devel@lists.sourceforge.net \
    --cc=lhcs-devel@lists.sourceforge.net \
    --cc=lhms-devel@lists.sourceforge.net \
    --cc=lhns-devel@lists.sourceforge.net \
    --cc=linux-hotplug-devel@lists.sourceforge.net \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pcihpd-discuss@lists.sourceforge.net \
    --cc=tokunaga.keiich@jp.fujitsu.com \
    /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).