lkml.org 
[lkml]   [2001]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: LANANA: To Pending Device Number Registrants
Linus Torvalds <torvalds@transmeta.com> wrote:

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

\
 
 \ /
  Last update: 2005-03-22 12:53    [W:0.037 / U:8.972 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site