OSDev.org

Brendan wrote:I typically have 3 things:

• VFS
• File systems
• Storage drivers

...
a storage device is mostly a file
...
A file system is something that mounts a file.
...
You can have multiple nested file systems.

HDD driver -> bytes ->
    -> partition filter -> partitions + bytes (content) ->
    -> FAT32 filter -> files + directories + bytes (content) ->
        -> GIF filter -> meta-data, image properties, ARGB data
    or
    -> NTFS filter -> files + directories + bytes (content) ->
        -> stream tokenizer filter -> tokens ->
            -> C++ parser filter -> AST
            or
            -> XML parser filter -> nodes

embryo2 wrote:An example of it.

Code: Select all

HDD driver -> bytes ->
    -> partition filter -> partitions + bytes (content) ->
    -> FAT32 filter -> files + directories + bytes (content) ->
        -> GIF filter -> meta-data, image properties, ARGB data
    or
    -> NTFS filter -> files + directories + bytes (content) ->
        -> stream tokenizer filter -> tokens ->
            -> C++ parser filter -> AST
            or
            -> XML parser filter -> nodes

onlyonemac wrote:My OS isn't quite like that but funny enough I've got a surprisingly similar design.

What I'm doing is assigning each file type a "class", and then the "class" implements functions that can act on the data. So for example a GIF file might extend class "@system.classes.mime.image.gif". Class "@system.classes.mime.image.gif" might implement functions "get_meta_data", "get_metrics" (width, height, colour depth, etc.), "get_pixels", and so on.

I'm also planning on implementing native formats, so like "@system.classes.native.image" which is a class of object with attributes "width", "height", "colour depth", "pixels", "title", "timestamp", "location", and so on.

I might also add the option for a "virtual attribute" as well, which would be an attribute that hooks into a function, so for example the GIF class might also have the same attributes as the native image class (it could extend the native image class) but the "pixels" attribute actually triggers a call to "get_pixels" every time it is read.

onlyonemac wrote:Hi,

I've got two layers of drivers: storage device drivers, and filesystem drivers. Both drivers have a single entry point, which is passed a parameter giving the desired function (for storage device drivers, things such as "read 3 sectors at offset 5 into the specified buffer"; for filesystem drivers, things such as "get the name of the next sibling to the specified node") and a number of parameters as required for the desired function (for example, the number and offset of the sectors to read and a pointer to a buffer to read them into). (In the event that the same driver is used for multiple devices or for multiple filesystems across different devices, multiple instances are used and are treated by the kernel as completely separate drivers.)

Now I'm wanting to pass my filesystem drivers two function pointers, one that will read an arbitrary sector from the underlying storage device and one that will write an arbitrary sector to the underlying storage device. These functions will take care of passing the request to the correct storage device driver, and of adding any offset to the requested sector (so that the filesystem driver can request "sector 0" and get the first sector of the partition where the filesystem resides, instead of the first sector of the entire device). Consequently, these functions will need to have some way of knowing which filesystem driver has called them so that they know which storage device driver to pass the request to.

So the question is, what is the best way to do this? So far I have thought of a few possible methods:

1. Copying a "template" function to a newly-allocated block of memory and patching it to hardcode some identifier for the storage device driver to use
2. Using a single function that is given to all filesystem drivers, which when called will perform a stack backtrace to determine which filesystem driver entry point function was called
3. Using a single function that is given to all filesystem drivers, and passing an additional "black box" parameter to identify the filesystem driver to the kernel and which the filesystem drivers are required to pass to the given "read" and "write" functions (this option might ultimately be the best, as the same "black box" parameter can be later used in other driver-to-kernel calls that might be added at a later time)

None of these sound particularly elegant to me. Is there an "official" way to do this? If not, which of these would be the best?

Thanks,

onlyonemac

• Write all functions, constants and variables with an ordinal prefix name like _0000000__. In this way you will also know what functions of which stage of your code development you are calling at all times. Do the same with source files (use ordinal names, an ordinal prefix and then the regular identifier name).
• You can also assign ordinals that will never ever change as in an API to your functions, constants and variables. For each subsystem you know or you can easily know which functions correspond (for example using a big wrapper or set of wrapper functions which you will always know what they are for).
  
  With the ordinals and with the system service wrapper functions themselves knowing what they are for, you will always know what is going on. It could be mastered at a level where you could know what you are doing with wrappers for your OS even if you used drivers and libraries intended for another system like Windows or Linux From Scratch.

embryo2 wrote:

onlyonemac wrote:My OS isn't quite like that but funny enough I've got a surprisingly similar design.

What I'm doing is assigning each file type a "class", and then the "class" implements functions that can act on the data. So for example a GIF file might extend class "@system.classes.mime.image.gif". Class "@system.classes.mime.image.gif" might implement functions "get_meta_data", "get_metrics" (width, height, colour depth, etc.), "get_pixels", and so on.

I'm also planning on implementing native formats, so like "@system.classes.native.image" which is a class of object with attributes "width", "height", "colour depth", "pixels", "title", "timestamp", "location", and so on.

I might also add the option for a "virtual attribute" as well, which would be an attribute that hooks into a function, so for example the GIF class might also have the same attributes as the native image class (it could extend the native image class) but the "pixels" attribute actually triggers a call to "get_pixels" every time it is read.

So, in fact it's OOP using procedural language. Why not C++?

And architecturally - converters/filters/transformers are just an encapsulation mechanism for the data structure knowledge. Such components help us to forget about details after the code is tested. But it's better not to forget about such components until there's a data in one of supported formats.

onlyonemac wrote:Also, writing the kernel in C++ would be a lot more work from the "supporting library" point of view, when C does the job perfectly. The kernel is somewhat of a microkernel, which is responsible only for fetching and updating the objects stored in the filesystem. This is a job that can be handled quite adequately with a few data structures and pointers.

onlyonemac wrote:

embryo2 wrote:

onlyonemac wrote:My OS isn't quite like that but funny enough I've got a surprisingly similar design.

What I'm doing is assigning each file type a "class", and then the "class" implements functions that can act on the data. So for example a GIF file might extend class "@system.classes.mime.image.gif". Class "@system.classes.mime.image.gif" might implement functions "get_meta_data", "get_metrics" (width, height, colour depth, etc.), "get_pixels", and so on.

I'm also planning on implementing native formats, so like "@system.classes.native.image" which is a class of object with attributes "width", "height", "colour depth", "pixels", "title", "timestamp", "location", and so on.

I might also add the option for a "virtual attribute" as well, which would be an attribute that hooks into a function, so for example the GIF class might also have the same attributes as the native image class (it could extend the native image class) but the "pixels" attribute actually triggers a call to "get_pixels" every time it is read.

So, in fact it's OOP using procedural language. Why not C++?

And architecturally - converters/filters/transformers are just an encapsulation mechanism for the data structure knowledge. Such components help us to forget about details after the code is tested. But it's better not to forget about such components until there's a data in one of supported formats.

It's more like OOP at the operating system level. The actual objects are made up entirely of (procedural) userspace code, which can be written in any language. There's actually very little OOP in the kernel.

Also, writing the kernel in C++ would be a lot more work from the "supporting library" point of view, when C does the job perfectly. The kernel is somewhat of a microkernel, which is responsible only for fetching and updating the objects stored in the filesystem. This is a job that can be handled quite adequately with a few data structures and pointers.

dseller wrote:My kernel is primarily written in C++, but I like the approach you have taken with the hierarchical class names.