I'm not a kernel hacker so I haven't a very good idea about how to
implement a compound object or whether it ought to be done in userspace or
kernelspace. It's the notion of why a compound object i usefull I want to
comment...
There is this underlying in unix (and i suppose most other OS's) that a
file may hold only one type of data. This makes it easy to handle the file
because the data type is homogenous throughout the file. The ordering
within the file is "start to end".
On the other hand, when programmer/user needs to compound different data
types, he may use directories to imply the underlying structure of his
data - like the kernel tree hierachy, often with a glue file (like the
Makefiles or a html file) or make the stucture himself within one file,
like it is seen in spreadsheets and documents. (I'm not saying that the
kernel tree is supposed to be one object...)
I think that structure within the file is often very tedious to work
with as a programmer (for different data types and non sequential data)
and the structure within directories too shaky and short lived. This is
(a little) like programming i F77 with no support for abstract data types.
You are able to make your own intrepretation of the data in an array to
suit your need for different interpretation of different data or your are
able to make a lot of arrays with each their own way of being handleded.
The filesystem is likewise lacking the properties of being able to
represent structure as anything else than flat data, so maybe new object
type is needed: "the filestruct" - which has one entry point but holds
different datatypes in different places. This filestruct would be a
formalization of the _structure_ of the data viewed as structure and _NOT_
as data. The point is that anything (I suppose) may be data but not
anything may be structure...
So all in all I think both a (more formalized) way of representing
structure in the filesystem and a new way of thinking of these thingies is
appropriate... why would anyone cat a structure? Or maybe that's what ls
does? After all structures are not sequential single type data objects
like most other files.
In C you're able to define your own structs, but is this needed for the
filestruct or could you have a fixed size struct with 1024 slots each
an ordinary file and the let the userspace program interpret the different
data with it's own standards for what is placed where (or maybe we'll get
a "640k limit" problem this way?)? Or maybe a set of standard
filestructs...
Try and look at your filesystem. Usually only one type of data per file
regardless of whether they actually belong together with another file of
different data type...
[THE_STUPID_Q]
Why is the header files split from both the library and the source/object
file? It's obviously no good without at least one of them? When you work
it is of course nice to have separated the header from the object and
source file since there's a more to one relation, but when you have
finished writing your lib?
[OFFTOPIC PS.:]
Just imagine writing the kernel in F77 :-)
Servicepack SR12 for NT. Available at www.linux.org
-- Morten S. Nielsen mailto:msn@ipt.dtu.dk
-- -- | Linux - the choice of a GNU generation | -- | Skaane Sjaelland Linux User Group | -- | at http://www.sslug.dk |
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/