Home ›

How the PCI Hot Plug Driver Filesystem Works

Issue 97

From Issue #97
May 2002

May 01, 2002  By Greg Kroah-Hartman
 in
Greg describes how the PCI Hot Plug core implements a RAM-based filesystem and how you can do the same for your drivers.
Acknowledgements

I would like to thank Pat Mochel for writing the ddfs/driverfs code upon which a lot of the pcihpfs code was originally based. driverfs is a new filesystem in the 2.5 kernel that will also help driver authors in exporting driver-specific information into user space, as well as provide a tree of all devices, making power management tools much easier.

I would also like to thank Al Viro for answering a lot of VFS-related questions and for enabling a filesystem to be written with such a small amount of code.

Resources

Greg Kroah-Hartman is currently the Linux USB and PCI Hot Plug kernel maintainer. He works for IBM, doing various Linux kernel-related things and can be reached at greg@kroah.com.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: How the PCI Hot Plug Driver Filesystem Works

Anonymous's picture
Submitted by Anonymous on Mon, 05/06/2002 - 02:00.

How do users mount the pcihpfs mount? Where is it located?

Re: How the PCI Hot Plug Driver Filesystem Works

gregkh's picture
Submitted by gregkh (not verified) on Mon, 06/10/2002 - 02:00.

To answer the second question first, it can be mounted where ever you want to.

To mount the filesystem do the following:

mount -t pcihpfs none /place/to/mount/pci_hotplug_filesystem

Re: How the PCI Hot Plug Driver Filesystem Works

tho_x_tran's picture
Submitted by tho_x_tran (not verified) on Wed, 10/16/2002 - 02:00.

First, I've just switched from Unix to Linux and willing to be educated. So please bear with my comments. Many systems that support Hot Plug PCI probably will have Doorbells and Latches. A hot plug operation on such a system should mostly be automatic, all user has to do is to insert the new card.

For such a system, I guess there should be some kind of a PCI hot-plug daemon running to intercept the "event" and does many things under the nose of the user.

Re: How the PCI Hot Plug Driver Filesystem Works

gregkh's picture
Submitted by gregkh (not verified) on Wed, 11/06/2002 - 03:00.

Yes, the individual PCI Hotplug drivers have a thread that watches to see if a latch has been opened or closed. If it changes state, it then goes through the power up (or down) sequence automatically, without user interaction.

Hope this helps.

Re: How the PCI Hot Plug Driver Filesystem Works

Anonymous's picture
Submitted by Anonymous on Thu, 05/02/2002 - 02:00.

Why goe to all the effort to write a new virtual filesystem. procfs was created a long time ago and can do everything you have created.

Is this not reinventing the wheel and making the kernel larger?

Re: How the PCI Hot Plug Driver Filesystem Works

gregkh's picture
Submitted by gregkh (not verified) on Mon, 06/10/2002 - 02:00.

procfs is a mess and it is not recommended to put new files into it.

As for making the kernel larger, in the 2.5 kernel, the libfs code that is already present, caused almost all of the filesystem specific code in pci_hotplug_core.c to go away, with only the PCI hotplug specific portions remaining. So there would not be any size savings by using procfs.

Webcast
More Resources
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers

Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.

Learn More

Sponsored by AMD

White Paper
More Resources
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions