Is everything a file ?

[Pype.Clicker]

I suppose most of you have read about Unix and its "everything is a file" motto. That's something i quite dislike in the Unix view. Why the hell must i give a filename to a pipe (bidirectionnal communication between programs, for windowish ones ) ? why must i give an inode number to character devices ? and what the hell is /proc ?

we're moving to a world where we'll us XML to describe dialog boxes ... isn't it time to find a better paradigm than unix files ?

The last two years, i've been busy designing a micro-kernel that features a generic naming system that allows any object of the system to be given a name. Unlike what occurs with Unix, once you looked up the symbol's name (and resolved "system.modules.atapi"), what you get is a pointer to the module structure, which you can use to perform any operations if you wish so (at kernel level at least). Of course, features like enumerations ("system.modules.*"), automatic UID assignment, indexing by UID, custom toString ("system.modules.atapi$" --> "kernel module, ATAPI drives support"), etc. are built-in. Symbols also have a type together with their value (so that you can check "system.name" is a string and "system.version" is an integer.

The purpose of this naming system is to

• help resolving symbols when loading a module
• unify the storage of the system parameters
• replace compile-time constants (things like the device identifier, error codes) by load-time or run-time resolved constants.

Now, i would like to have your opinion ... is it an improvement in OS design or did i just lost my time reengineering the wheel ?

[klalafuda klalafu]

you'r not obliged to explicitly name a file, do you ? socket(), pipe(), socketpair(), unlink() at the end of all and so so on...

file - is a file. and dosn't have a name in general. that's just a communication record in OCBs table

// wbr

[DarylD]

I like Pype's idea as it shares some traits with mine but I haven't taken it quite this far.

I personally dont like the unix mentality, I quite like the idea of loaded modules with thier own calls without using command-line utils. And enumeration is great!

The idea of a generic module interface for everything is a good idea in my eyes, so basically I voted for the second option.

Anyway, would type more but my fingers are frozen...bloody snow.

Daryl.

[distantvoices]

Each of you is right: Be it a File, be it a named object listed in some enumeration, it comes out to one point: abstract some things to make life easier for the programmers and the users.

ad named pipes: They have Sense: You have two different processes which have to talk together: Best way to do this is via named pipe.

Unnamed pipe is usually opened by processes which share their code and one opens the pipe for writing whilst the other opens it for reading and the two of them know about each other via this pipe (exactly, first process spawns second process and tells him about this pipe.)

ad file: It is a nice way to abstract things.

ad /proc: this is a part of virtual file system which is about processes and some general things the kernel has recorded.

I think it is good abstraction to have "everything" in the system be a file.

[_mark]

There is a true beauty in the unix file system. Under what other OS can you simply take a normal console application that reads from stdio and writes to stdout and turn it into a full fledged internet server by adding one line to a config file. The beauty is in it's simplicity. It is efficiant, elegant, an more robust then any other alternative out there.

Of course you are all familiar with interfaces right??? If not, you should be! The unix file system provides a single well defined interface for ALL devices on a system. It allowes for accessing shared memory, it allowes for accessing kernel objects. You can basically do anything only knowing a few simple system calls:
read,write,seek,tell,fctl etc...

IMHO there is no other way to go.

Mark

[2100-OS]

Files, tables, devices, in every OS there are nice things and not so nice things (well, in some the second option is almost the only one appliable, you-now-which).

But it comes all to a point where men designed something to do some or more things. If a design choice is made, it's based on the way users and developers like to use it. The problem however, which is appliable to almost every OS, is too keep these ways up to date. If you look at the previous mentioned you-now-which OS, you'll be able to notice that there are structures with the most bizarre names and methods with at least 10 or more arguments. This is due the continue redesign of an OS.

In my opinion, it's important to make a kernel and an OS which is very flexible, so it can be changed pretty fast.

To be honest with you, I dislike devices which are represented as files, though it is practical in some cases, it's also confusing. I like a more split up approach, but as I said, it's difficult what a developer or user wants to have.

[elias]

i havnt done any real work on my OS cuz im busy with something else now, but im planning as treating everything as a module, except for data files. The reason everything is a file under UNIX is that its really easy and flexible.

[chrisa128]

I don't like the file approach much, I am thinking of making everything an object and so would be interested in seeing what you have done.

The file way is good but doesn't have the customisbility I need...

Please give me more info!!!!

[Pype.Clicker]

what i dislike a lot with "everything is a file" approach is the need for a charcaters line parser to know how much CPU time a process has consumed in Linux (plus a bunch of manpages explaining how to decode that line of digits).
Imho, you should have the opportunity to ask for
Lookup(rLookup("system.info.process.*",current_pid()),"used_time")

Now, some people would tell me XML could make that /proc filesystem more comprehensive ... but it would be even more complicated to handle (i don't feel like having an XML parser in a kernel)...

info about KDS (Kernel DynamiX System), the system information model used in Clicker can be found at http://clicker.sourceforge.net/docs/cak ... rview.html, and its Object-Oriented extension is described here.

For source files, check kernel/kds/* in the latest source release (the version in CVS is currently being restructured to add a new feature: kdsDomains, allowing the KDS naming & services to extend across multiple address space

[srg]

When thinking about it, the unix file system is a good idea, I just feel that unix's interpretation of the idea is too complicated and confusing to those that are not familliar with it (like me), it simply, in my oppinion needs simplifying and restructuring.

[Tim]

The only problem I have with the 'everything is a file' concept is that you end up with 90% of functionality shoved into ioctl(), and the rest into read() and write(). I think that a unified namespace which looks like a file system is a good idea, but treating every OS object as a stream of bytes isn't.

[elias]

now that i think about it, what do you do to an object, other than read to it and write from it? the file approach is quite good. i finally see taht in my approach, all im doing is replacing the word "file" with " module" basically

[Pype.Clicker]

the difference is that an object is structured. So you can naturally learn what it contains by enumerating its fields.

"system.modules.floppy.*" --> "base limit refcount ..."
"system.modules.floppy.refcount" --> (integer) 2
...

For sure, the same could be achieved by making "/procsystem/modules/floppy" be a directory and listing it. But then you'd need to "open" /.../floppy/refcount" before you can read it. And when you read it you must detect end-of-line, which requires some buffer-space,etc.

Moreover, like Tim said, you can just read and write, which leads to weird situations like Linux Security Module which can be unloaded only by writing "reboot" in /proc/security ... what about simply invoking that command with "system.modules.floppy!unload" ? ...

[Tim]

Exactly. Why should you be restricted to read, write and ioctl methods for everything? Why not have a full set of 'methods' for different objects? At the system level, reboot could be:

Code: Select all

security = ObOpen(L"/proc/security");
ObInvoke(security, Security_Reboot);
ObClose(security);

And for normal file system access:

Code: Select all

file = ObOpen(L"/hd/files/whatever");
ObInvoke(file, File_Read, buffer, sizeof(buffer));
ObClose(file);