On Fri, 11 Oct 2002, Steven Dake wrote:
| > On Thu, 10 Oct 2002, Steven Dake wrote:
| >
| > | I am developing the Linux kernel support required to support
| Advanced
| > | TCA
| > | (PICMG 3.0) architecture. Advanced TCA is a technology where boards
| > | exist
| > | in a chassis and can either be processor nodes or storage nodes.
| All
| > | blades in the chassis are connected by FibreChannel and Ethernet.
| The
| > | blades can be hot added or hot removed while the Linux processor
| nodes
| > | are
| > | active, meaning that the SCSI subsystem must add devices on
| insertion
| > | requests and remove devices on ejection requests.
| > |
| > | The following is the first public patch that I am posting that adds
| > | support
| > | for SCSI and FibreChannel hotswap via a programmatic kernel
| interface,
| > | as well as userland access via ioctls.
| >
| > Thanks for letting us know about it.
| > Does this project have a web page?
|
| I will post a sourceforge project later today if I have a chance. My
| mailer
| Is broken and is reformatting patches and its easier just to post a
| link.
Yeah. :)
| > | The second patch is a FibreChannel driver that is modified to
| support
| > | SCSI hotswap.
| > |
| > | This mechanism is far superior to /proc/scsi/scsi because it:
| > | 1) provides true FibreChannel hotswap support (at this point qlogic
| FC
| > | HBAs)
| > | 2) is programmatic such that errors can be reported from kernel to
| user
| > | without looking is /var/log/.
| >
| > so where does someone look for errors?
|
| Someone would use return codes, as defined by errno.h to understand how
| An error occurred. Things are ENOMEM, ENOENT, etc that describe the
| exact
| Error. The previous mechanism required looking in /var/log to see if
| the Command was completed.
Aha, "user" is software, not a humanoid. I see now.
| > | 3) Provides superior response times vs opening a file and writing to
| > | proc.
Does the software doing this still have to open a file
and execute an ioctl?
Instead of opening a proc file and writing to it?
| > | 4) Easier to control from kernel and user via C APIs vs using
| > | open/write.
| >
| > Does this suggest adding yet another hotswap/hotplug mechanism
| > to Linux? It would be a good thing to unify them IMHO.
|
| I am not suggesting adding yet another PCI hotplug mechanism. What I am
| suggesting is adding a SCSI Device hotswap mechanism. The current
| technique
| is currently unsupported (emails to the author bounce) and lacking in
| several
which one are you talking about?
| key areas. I'd prefer to just remove the /proc/scsi/scsi proc
| interface,
| but I'm sure that would raise the ire of users everywhere and will let
| someone else fight the cleanup battle. :)
Agreed.
| > Does this hotswap mechanism require userspace software to activate it?
| > If so, is it available or being developed also?
|
| The interfaces for hotswap are available from both kernel and via an
| IOCTL
| interface to userspace. I've also implemented shell commands to support
| hotswap for those users that wish to script the commands.
|
| As a side note, I see you are involved in OSDL. These patches are
| already part of the OSDL CGLE trees.
So they are.
There are many things hidden in the CGL diff against plain vanilla
2.4.18, totaling around 9 MB and 288K lines.
I haven't looked at all of it yet. :(
-- ~Randy "In general, avoiding problems is better than solving them." -- from "#ifdef Considered Harmful", Spencer & Collyer, USENIX 1992.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 22:00:42 EST