>On Tue, 15 May 2001, Alexander Viro wrote:
>> Driver can export a tree and we mount it on fb0. After that you have
>> the whole set - yes, /dev/fb0/colourspace, etc. - no problem. And no
>> need to do mknod, BTW. Yes, we'll need to use /dev/fb0/frame for
>> frame itself. BFD...
>
>Actually, we can just continue to use "/dev/fb0", which would continue to
>work the way ti has always worked.
>
>It's a mistake to think that a directory has to be a directory. Or to
>think that a device node has to be a device node. It's perfectly ok to
>just think of it as namespaces. So opening /dev/fb0 continues to open the
>"master fd", whatever that means (in this case, the actual frame
>buffer). The namespaces _under_ /dev/fb0 would be the control channels, or
>in fact _anything_ that the frame buffer driver wants to expose.
Why not take it a step further than just devices? This is a perfect
model for supporting named forks.
In fact, I believe this is how MacOS X is exposing HFS+ named forks to
the UNIX side of things. (HFS+ supports not just the old style
Macintosh data and resource forks but an arbitrary number of named
forks.) So: you open "foo", you get what an older MacOS would consider
the "data" fork. Open "foo/rsrc" and you get the resource fork. Open
"foo/joesfork" and you get whatever Joe wanted to use a named fork for.
-
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/