Virtual devices

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
User avatar
ManOfSteel
Member
Member
Posts: 60
Joined: Tue Feb 01, 2005 12:00 am

Virtual devices

Post by ManOfSteel »

Hello,
I would like to know how are virtual devices (like NUL), implemented in MS-DOS.
Thanks in advance.
User avatar
JamesM
Member
Member
Posts: 2935
Joined: Tue Jul 10, 2007 5:27 am
Location: York, United Kingdom
Contact:

Post by JamesM »

The implementation of virtual devices really depends on the implementation of your filesystem. Usually* the filesystem is implemented as a tree of nodes each with function pointers for read(), write() etc. You would create a node whose function pointers point to special 'virtual device' functions that operate in a different way from normal nodes.

At least that's the way I do it, and it seems to be the obvious way. As for MS-DOS, I'm not sure of the actual implementation!


* 'usually' may be the incorrect word ;)
User avatar
ManOfSteel
Member
Member
Posts: 60
Joined: Tue Feb 01, 2005 12:00 am

Post by ManOfSteel »

Virtual devices have been implemented in different ways. For example in MS-DOS you won't find any file named NUL while in Unix and Linux you can find /dev/null. I think it is implemented in the shell in MS-DOS instead of the file system, yet I never found it in "command.com".
Usually* the filesystem is implemented as a tree of nodes each with function pointers for read(), write() etc. You would create a node whose function pointers point to special 'virtual device' functions that operate in a different way from normal nodes.
I'm not sure I follow. What are those function pointers? And how are they related to files or their i-nodes?
User avatar
Brynet-Inc
Member
Member
Posts: 2426
Joined: Tue Oct 17, 2006 9:29 pm
Libera.chat IRC: brynet
Location: Canada
Contact:

Post by Brynet-Inc »

On most Unix-like systems, "device nodes" represent a specific "device" using major and minor numbers..

/dev/null for example on OpenBSD:

Code: Select all

[brynet@ttyp0]/dev: $ file null
null: character special (2/2)
[brynet@ttyp0]/dev: $
OpenBSD has a two device nodes for terminal/serial/com ports, one which getty can listen for incoming connections on and another used for outgoing connections.

Code: Select all

[brynet@ttyp0]/dev: $ file tty00
tty00: character special (8/0)
[brynet@ttyp0]/dev: $ file cua00
cua00: character special (8/128)
[brynet@ttyp0]/dev: $
Device nodes are usually created with the mknod command :)

The mknod command itself though is just a front-end to the mknod library function, Which has been around since AT&T Unix V6 8)

See: http://en.wikipedia.org/wiki/Device_node and http://en.wikipedia.org/wiki/Special_file
Image
Twitter: @canadianbryan. Award by smcerm, I stole it. Original was larger.
User avatar
JAAman
Member
Member
Posts: 879
Joined: Wed Oct 27, 2004 11:00 pm
Location: WA

Post by JAAman »

Virtual devices have been implemented in different ways. For example in MS-DOS you won't find any file named NUL while in Unix and Linux you can find /dev/null. I think it is implemented in the shell in MS-DOS instead of the file system, yet I never found it in "command.com".
no, its not part of the shell, its part of the filesystem -- or more specifically, part of the OS internal redirection

when you display the directory, all DOS does is copy the directory structure from disk onto the display -- but there is no 'null' entry on the physical disk, neither is there a 'prn' or 'con' (2 more device entries which can be accessed as if they were files located in every directory on every disk)

this is part of the OS, applications can open them as if they were files, and the user can use them on the cli as if they were files, and the shell opens them just the same as it would any other file -- the operating system sets up a link to the appropriate device each time a handle is opened to that device, just the same as it does to a file -- except the handle points to the appropriate i/o stream instead of to a file on the disk
Post Reply