Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map) | Date | Mon, 24 Jun 2002 15:54:28 +0200 |
| |
Grover, Andrew <Andrew.grover@intel.com> wrote on Sun Jun 23 2002:
> I know this is one of those things that has more and more cool > possibilities the more you think about it but... > > Is the device PHYSICALLY hooked up to the computer? If not, it shouldn't > be in devicefs.
So what do you do when none of the devices you are using is physically attached :-) ? On s390, we have an abstraction layer that allows us to use virtual devices without knowing the true hardware behind it. All we see is an 'i/o subchannel' that typically equals a device (disk, tape, console etc.).
I decided not to care about virtualization and have a device node in driverfs for each subchannel. Unfortunately, there are some devices (e.g. ethernet controllers) that are made up by multiple (two or three) subchannels, because some hardware engineers decided that it was a good idea to do that (for a good reason).
Now I have an extra bus type for those devices. They often do exist physically (and I don't care if they are only virtual), so they need a place in the device tree. Currently, each such device is a child node of one of the subchannels. This is not how it is meant to be in driverfs (there is no network device connected to a subchannel device, the network device _is_ two subchannels), but what else should I do there?
Other drivers are purely virtual. The Inter-User Communication Vehicle (iucv) lets me set up a network interface between two virtual machines. I don't need a driverfs interface for it, but why shouldn't I have it anyway? It even fits the driver model better that my physical network devices!
Arnd <>< - 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/
| |