lkml.org 
[lkml]   [2002]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] /proc/scsi/map

[ Sorry for the lack of noise in the last week; I was unable to read email
for the last week, and am only starting to catch up. ]

> Try it out yourself. Just do
>
> mount -t driverfs /devices /devices
>
> and then look at the whole glory in some graphical file manager to get a
> view of the tree (actually, most file managers are somewhat confused about
> the fact that the directory counts don't reflect sub-directories, so you
> may have to open the subdirectories by hand, whatever. That's a bug.
> Should be fixed. I'm cc'ing Pat)

ACK. I'm looking into it; should have something before I leave for Ottawa.

> End result: Linux has a notion of a "struct device", and it's an internal
> kernel representation of the whole bus structure as far as Linux can tell.
> It's then exported as a filesystem, but that's not the important part: the
> device tree is valid (and important) even when it's not exported to user
> space, simply because things like power-management events etc have to
> honor the tree and traverse it in the right order.

This is an important point, and one I will be stressing heavily in Ottawa.
The device model != driverfs. The new device model is about refining the
kernel representation of device-related objects: devices, drivers, bus
drivers, and class drivers.

A filesystem just happens to map very nicely onto internal hierarchial
structures, which is why it was created. driverfs makes no sense with the
device model infrastructure to populate it. But, the device model core can
theoretically be separated from the driverfs implementation.

> If you like OF, you can actually use OF to _populate_ the Linux device
> tree. The people who like ACPI (yet, they exist) do that with ACPI. The
> Linux device tree is _completely_ agnostic, and absolutely does _not_ want
> to know or depend on firmware issues, since firmware is not portable.
>
> (Right now ACPI does this, so all the strange ACPI nodes will show up in
> /devices/root/ACPI if you have ACPI enabled).

I made a patch a while back that mapped ACPI-enumerated devices back to
physical objects in the system. This got rid of the duplicate ACPI
entries, and should be done generically enough to port it to other
firmware enumerators. (It depends a couple of other patches that have not
made it out yet, but I'll bring the whole slew to Canada so people can
see how it works).

OF wrt the device tree is something I've talked to a few people about.
Things were much more nebulous than now, and talk is still cheap. Ideally,
OF should populate the device tree in a similar manner, but I don't think
anyone has had the time to make it happen...

-pat

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

\
 
 \ /
  Last update: 2005-03-22 13:26    [from the cache]
©2003-2011 Jasper Spaans