Investigated streams more, and I have created a "FILE" structure that actually just creates a queue buffer similar to those I already have. It means that I can now use generic functions to interact with them, and improve their complexity later on.
Looking now at expanding the definitions of the device and file system drivers to head toward my previously designed Dos abstraction layer.
If I'm going to have to parse this mountlist in order to derive all the required information, it would make sense to implement the C library strtok function, which is what I'm doing now.
Ok, String_strtok() seems to work, and I copied the example mountlist in to test in on that. A few tweaks and I should have the routine to parse the mountlist for the devices.
Dropped strtok because it won't work in this situation. It would be valid to have no space between the name and the equals sign, which would leave us no room for the null terminator. I have instead parsed the mountlist by hand into a "sanitised" mountlist string. The sanitised string is then being parsed again and copied into the appropriate Dos device structure. Now I need to change the Library loader so that it can return a reference to the library if it is already loaded, then get the Dos system to find the library (filesystem driver, device driver) specified in the entry and initialise the device.
I've updated the Fat driver and the Ram driver to expose their interface structures with a name that won't clash with other things, and I've added them both as entries in the Kernel library so that they can be found by name when referenced by the mountlist
The Dos system is now pulling the device and the filesystem out of the mountist definition and looking them up in the library. I also have them calling the CreateContext routines and passing the definition. Now I need to get the CreateContext functions to create the appropriate context element from the settings in the mountlist.
No comments:
Post a Comment