OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 1:55 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 5 posts ] 
Author Message
 Post subject: What is the best way to implement DIR function into my OS?
PostPosted: Fri Aug 31, 2018 5:23 am 
Offline
Member
Member
User avatar

Joined: Sat Sep 17, 2016 2:14 am
Posts: 83
Location: Moscow, Russia
Hello there,
How do I implement a DIR function in a best way into Commodore (yes, that's the name, no relation to Commodore 64) OS (bits taken from the OSDev wiki)?
I've got some functions working, such as ver, hi and help.
Sincerely,
Tim Williams

_________________
Coffee is not airplane fuel.


Top
 Profile  
 
 Post subject: Re: What is the best way to implement DIR function into my O
PostPosted: Fri Aug 31, 2018 11:04 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

TimothyWilliams wrote:
How do I implement a DIR function in a best way into Commodore (yes, that's the name, no relation to Commodore 64) OS (bits taken from the OSDev wiki)?


The best way goes something like:
  • Task asks VFS (Virtual File System) to open the directory
  • VFS checks its caches
  • If the data isn't in the VFS caches:
    • VFS records a "pending request" somewhere to keep track of it
    • Possibly (if it was a synchronous function call) VFS blocks the task that asked for directory info so it doesn't get any CPU time
    • VFS figures out which file system/s contain the directory info and asks them for the directory info
    • The file system/s do whatever they feel like (fetching blocks from storage device, etc) to try to obtain the directory info that the VFS asked for.
    • When file system/s have any information (either the directory contents or a "directory doesn't exist" status); they give this information back to the VFS
    • VFS uses the information from file system/s to update its cache
    • VFS finds the "pending request" it recorded earlier
    • Possibly (if it was a synchronous function call) VFS unblocks the original task that asked for directory info
    • If the directory doesn't exist; VFS returns "failed" to the task that asked to open the directory
  • Now that the information must be in the VFS cache; VFS does permission checks to determine if the task that asked to open the directory is allowed to open the directory
  • If permission checks fail, VFS returns "failed" to the task that asked to open the directory
  • VFS marks the directory info in its cache as "in use" in some way (so that it's not evicted from cache before its used; and possibly so that if the directory info changes while its being read a copy of the old information is kept so that the reader doesn't get confused by an inconsistent/changing mess).
  • VFS returns "success" to the task that asked to open the directory
  • If VFS returned "failed", the task can't get the directory and stops trying.
  • If VFS returned "success":
    • The task probably has a loop that asks VFS for "N directory entries" at a time (where N might be one - e.g. if the C library's implementation of "readdir()" is simple and doesn't buffer anything to reduce overhead of VFS requests)
    • The task tells VFS to close the directory (or terminates or crashes or something)
    • VFS removes the "in use" mark that it created when opening the directory previously

Notes:
  • There might be 1234 different processes pounding the daylights out of the VFS at the same time, including multiple processes asking the VFS to open or read the same directory at the same time. Because of this, file systems (and storage device drivers) should be asynchronous so that the VFS doesn't have to wait for one thing (needed for one process) before doing other things (for other processes).
  • VFS also has to handle "unexpected loss of file system" at any point - e.g. if the user unplugs a USB flash memory stick at the wrong time (and storage device driver tells file system/s, and those file system/s tell VFS "file system suddenly vanished").
  • For performance (and to handle extremely huge directories on computers that don't have much RAM) the VFS might not fetch all directory info when the directory is being opened (and might be asking file system/s for directory information to add to its cache while task/s are asking to read the directory entries from its cache).


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: What is the best way to implement DIR function into my O
PostPosted: Fri Aug 31, 2018 3:22 pm 
Offline
Member
Member
User avatar

Joined: Sat Sep 17, 2016 2:14 am
Posts: 83
Location: Moscow, Russia
Brendan wrote:
Hi,

TimothyWilliams wrote:
How do I implement a DIR function in a best way into Commodore (yes, that's the name, no relation to Commodore 64) OS (bits taken from the OSDev wiki)?


The best way goes something like:
  • Task asks VFS (Virtual File System) to open the directory
  • VFS checks its caches
  • If the data isn't in the VFS caches:
    • VFS records a "pending request" somewhere to keep track of it
    • Possibly (if it was a synchronous function call) VFS blocks the task that asked for directory info so it doesn't get any CPU time
    • VFS figures out which file system/s contain the directory info and asks them for the directory info
    • The file system/s do whatever they feel like (fetching blocks from storage device, etc) to try to obtain the directory info that the VFS asked for.
    • When file system/s have any information (either the directory contents or a "directory doesn't exist" status); they give this information back to the VFS
    • VFS uses the information from file system/s to update its cache
    • VFS finds the "pending request" it recorded earlier
    • Possibly (if it was a synchronous function call) VFS unblocks the original task that asked for directory info
    • If the directory doesn't exist; VFS returns "failed" to the task that asked to open the directory
  • Now that the information must be in the VFS cache; VFS does permission checks to determine if the task that asked to open the directory is allowed to open the directory
  • If permission checks fail, VFS returns "failed" to the task that asked to open the directory
  • VFS marks the directory info in its cache as "in use" in some way (so that it's not evicted from cache before its used; and possibly so that if the directory info changes while its being read a copy of the old information is kept so that the reader doesn't get confused by an inconsistent/changing mess).
  • VFS returns "success" to the task that asked to open the directory
  • If VFS returned "failed", the task can't get the directory and stops trying.
  • If VFS returned "success":
    • The task probably has a loop that asks VFS for "N directory entries" at a time (where N might be one - e.g. if the C library's implementation of "readdir()" is simple and doesn't buffer anything to reduce overhead of VFS requests)
    • The task tells VFS to close the directory (or terminates or crashes or something)
    • VFS removes the "in use" mark that it created when opening the directory previously

Notes:
  • There might be 1234 different processes pounding the daylights out of the VFS at the same time, including multiple processes asking the VFS to open or read the same directory at the same time. Because of this, file systems (and storage device drivers) should be asynchronous so that the VFS doesn't have to wait for one thing (needed for one process) before doing other things (for other processes).
  • VFS also has to handle "unexpected loss of file system" at any point - e.g. if the user unplugs a USB flash memory stick at the wrong time (and storage device driver tells file system/s, and those file system/s tell VFS "file system suddenly vanished").
  • For performance (and to handle extremely huge directories on computers that don't have much RAM) the VFS might not fetch all directory info when the directory is being opened (and might be asking file system/s for directory information to add to its cache while task/s are asking to read the directory entries from its cache).


Cheers,

Brendan

Lemme explain: I am having trouble finding the long lost snippet of code from DonkersOSYD's tutorial (Part 7).

_________________
Coffee is not airplane fuel.


Top
 Profile  
 
 Post subject: Re: What is the best way to implement DIR function into my O
PostPosted: Fri Aug 31, 2018 5:13 pm 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

TimothyWilliams wrote:
Lemme explain: I am having trouble finding the long lost snippet of code from DonkersOSYD's tutorial (Part 7).


I found the DonkersOSYD's web site, but there's only 5 parts and they all look like a beginner's first day. Unless the 6th part is 700 pages (covering protected mode, memory management, scheduling, PCI enumeration, IRQ handling, storage device drivers) I doubt the long lost snippet of code from the 7th is worth finding.


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: What is the best way to implement DIR function into my O
PostPosted: Sat Sep 01, 2018 2:46 am 
Offline
Member
Member
User avatar

Joined: Sat Sep 17, 2016 2:14 am
Posts: 83
Location: Moscow, Russia
Brendan wrote:
Hi,

TimothyWilliams wrote:
Lemme explain: I am having trouble finding the long lost snippet of code from DonkersOSYD's tutorial (Part 7).


I found the DonkersOSYD's web site, but there's only 5 parts and they all look like a beginner's first day. Unless the 6th part is 700 pages (covering protected mode, memory management, scheduling, PCI enumeration, IRQ handling, storage device drivers) I doubt the long lost snippet of code from the 7th is worth finding.


Cheers,

Brendan

Well, damn. I guess I'll have to figure it out myself.

_________________
Coffee is not airplane fuel.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Google [Bot] and 60 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group