[lkml]   [2002]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: driverfs is not for everything! (was: [PATCH] /proc/scsi/map)
Grover, Andrew <> 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

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

Arnd <><
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 13:22    [W:0.037 / U:1.524 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site