OSDev.org

Hi All,

I now have a basic working task manager, device manager, TUI (which just has a 'help' command at present!) and everything seems to be going fairly smoothly so far.

I'm now thinking about my system directory structure and wondered how the OS normally interprets paths accessed by apps. To clarify:

The user app may access /dev/hda1/x - at some point the character array "/dev/hda1/x" needs to be interpreted by the kernel and the correct device selected. If on the other hand I have something like "/root/processes", I need to enter a state where the app can get information from my task manager. I'm thinking that perhaps it should be the job of the device management system to interpret this information at the moment. The alternative would be to have a separate "Path Interpretation Module" that parses paths and passes (try saying that when you're drunk ) requests on to the appropriate kernel module or device driver.

Also, once an app has changed to a particular "current directory", I also need to keep track of that. I'm wondering whether the runtime should keep track of this infomation in user space and pass the full path to the kernel on every call, or whether the kernel should keep track of the current directory and just allow relative paths to be passed from user space.

It's not so much the string manipulation I have problems with, it's more the concepts - I come from a Windows background but would like to access my devices like files - as in unix-type systems.

Does anyone know of any decent reading material about how other systems deal with this?

Thanks,
Adam

If you are going to treat devices as files, there has obviously got to be some kind of low level code (probably just above the device driver level) which distinguishes between the two, and then routes read/write/open/close requests etc to their appropriate destination. As far as higher level kernel processes are concerned, I suppose a path is a path is a path. If you try to deal with it at too high a level you lose the point of the abstraction.

I would say that it's the kernels job to keep track of the current directory. Paths passed from user space could be either relative (to the current directory) or absolute (relative to the root directory).

By the way, if you tried to use fopen to open a device in Windows, I am pretty sure you would succeed.

Could your device manager, or some part of it, itself become a "device", in the sense of being structured as a device driver? Possibly it would be a character device, or maybe (given its unique role) it would live in a category all of its own. (For a start you wouldn't want to close it.)