OSDev.org

AbstractYouShudNow wrote:That would be interesting, since your drivers could be implemented in either user-space or kernel-space, or both. However, I think you would lose quite a lot of time in system calls and interprocess communication. That being said, if your kernel is a microkernel, you will benefit much from that model.

One last thing I would add is that you didn't mention security in your description. I think you should add some restrictions on the access to objects, since some objects should nnot be accessible by everyone. For example, a graphics driver's object should only be accessible by the GUI server, and the disk driver should only be accessible to the VFS server or programs that are granted the "raw disk access" priviledge (or simply administrator priviledges in Windows).

Have you started to implement it already ?

Jezze wrote:The reason why files are used and not objects is that because if you add new objects to the system, every program that doesn't know about this new type needs to be updated to be able to use them, you dont have that problem to the same extent with files. Have you thought about that?

Jezze wrote:The first part sounds very much like what a normal device driver interface would look like and the rest sounds very similar to Plan9 and it's 9P protocol except it uses objects instead of files. It sounds pretty solid in theory but there might be a bunch of problems that show up because it requires a lot of implementation work before you can really show it works and therefor it is very hard at this stage to argue the benefits.

You could say that files are pretty good at representing resources and they can in fact represent every type of resource in a system but they are certainly not the most efficiant way to do it in most cases. What all resources have in common is that you want to able to read and write data from them which files can handle perfectly well. Then its up to the implementer of a resource to decide what granularity they want. Should a file represent a structure of data or a single value or something inbetween. This is where files have no clear set of rules while with objects you don't really need to think about it.

The reason why files are used and not objects is that because if you add new objects to the system, every program that doesn't know about this new type needs to be updated to be able to use them, you dont have that problem to the same extent with files. Have you thought about that?

Have you thought about how you will navigate resources? Will you query them like SQL or present them hierarchaly like a normal filesystem? Why I am worried here is that if you unify all resources into one huge database it could become very slow.

rdos wrote:It basically sounds like a reasonable way to do it, except that I think that the central object manager is a flawed concept which would lead to the same problems that files/IOCTL and Windows handles have. The thing is, you don't want one common object model, you want one object model per device-type. So you want to have a file interface with methods adapted for files, a directory interface with directory-related methods, a sound interface to playing sounds, a graphic interface, a mouse-interface, a touch-pad interface, a socket interface and so on. You should define standard object interfaces for these basic classes, and then you provide physical adaptations for those, and thus gain device-independence.

The way I do it in my OS, is that I have a module that implement handles (creating, dereferencing, deleting), but that doesn't know the purpose of the object it protects. Then I have a list of handle-types which are associated with each handle. When a handle is dereferenced, the handle type is passed and checked, which makes sure that handles are of the correct type.

Brendan wrote:Hi,

Jezze wrote:The reason why files are used and not objects is that because if you add new objects to the system, every program that doesn't know about this new type needs to be updated to be able to use them, you dont have that problem to the same extent with files. Have you thought about that?

That's not quite right.

In systems that use "files" for device driver interfaces you end up with a whole bunch of problems (caused by lacking functionality) because devices aren't files at all and need to support device specific things that are more than just transferring data. This is followed by IOCTLs as a work-around for the missing functionality problem, followed by "every program that doesn't know about this new set of IOCTLs needs to be updated to be able to use them".

linguofreak wrote:One thing I've mused about at times is using directories for device driver interfaces. Each device file on a traditional Unix system gets turned into a directory holding at least a "ctl" file and a "data" file. The "data" file takes over the role of the original device file, and instead of using ioctl(), processes write command strings to the "ctl" file. So you might have /dev/fb0/ctl and /dev/fb0/data (or, for back-compatibility with existing Unixes /dev/fb0dir/ctl and /dev/fb0dir/data, with /dev/fb0 being a symbolic link to /dev/fb0dir/data, and ioctl() being a userspace libc function that opens and writes to /dev/fb0dir/ctl).

Wikipedia wrote:Unlike most other operating systems, Plan 9 does not provide special application programming interfaces (such as Berkeley sockets, X resources or ioctl system calls) to access devices. Instead, Plan 9 device drivers implement their control interface as a file system, so that the hardware can be accessed by the ordinary file input/output operations read and write.

Jezze wrote:If it means that you as a programmer needs to supply a GUID in order to access a certain resource I'd would say no way. I somehow think that it should be possible to fix collisions using namespaces somehow so that they wouldnt conflict with eachother and if you get a conflict when trying to add a new resource it would fail similar to what would happen with a a "file already exists" or possibly it could replace / shadow the resource which could be kinda neat because then you could create specialized resources that replaces more generic ones. A third option would be to merge the resources. I dont really know what would be the best option for you.

Audio
    Audio.MP3
    Audio.WAV
    Audio.WMA  
Image
    Image.BMP
    Image.JPG
    Image.PNG
System
    System.Graphics
        System.Graphics.Canvas
        System.Graphics.Window
    System.IO
        System.IO.File
        System.IO.Section
    System.IPC
        System.IPC.Queue
        System.IPC.Pipe
        System.IPC.Socket
        System.IPC.Semaphore
        System.IPC.Mutex
        System.IPC.RWLock
        System.IPC.Timer

Marionumber1 wrote:Those ideas could work very well. I'm thinking of structuring my classes in a hierarchial namespace, sort of like how .NET does it. It could work somewhat like this:

Code: Select all

...
System
    System.Graphics
        System.Graphics.Canvas
        System.Graphics.Window
    System.IO
        System.IO.File
...