This is the
talk page for discussing improvements to the
Device file article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||
|
![]() | The contents of the /dev/hda page were merged into Device file on 4 November 2010. For the contribution history and old versions of the redirected page, please see its history; for the discussion at that location, see its talk page. |
FreeBSD has done away with Block Devices. Some more should be written about this in the Character Device section. —Preceding unsigned comment added by 192.156.198.15 ( talk) 19:52, 5 January 2010 (UTC)
I'd like to suggest a re-write please. Perhaps based on sectioning information pertaining to Linux, Windows and BSD? For example, the Windows references are not clearly differentiated here. Notice that the third sentence follows a second sentence Windows reference. Does the word "They" in the third sentence refer to Windows systems, to Unix-Linux systems or to both? Maybe references to Windows differences should appear later in the article since the article points out that Windows borrowed the concepts from Unix? Clearly set off so that people can find the system they need described? — Preceding unsigned comment added by 70.253.70.197 ( talk) 01:08, 3 April 2012 (UTC)
The tone of voice in the devfs section is opinionated. The section is also out of place in its context. It only serves to confuse the reader, especially when the table below it makes clear that devfs is deprecated now. Gwrede ( talk) 09:50, 22 April 2009 (UTC)
There is another article by the name of Device name. (Which was made before this one) I was thinking about either merging it into this one (under the Device Files heading), or linking them with See Also links. Do you think the Device name article is significant enough to keep it separate, or should it be merged? I would probably completely replace the table under Device Files with the contents of Device name, as Device name has a lot more information. Otherwise the See Also links are trivial. -- NerdBoy1392 < Talk| Contribs> 23:44, 19 October 2008 (UTC)
The result of the move request was page moved to device file. Skomorokh 10:25, 27 December 2009 (UTC)
Device file system → device special file — This page mainly discusses the concept of a device special file, not the concept of a special file system that contains device special files It can continue to discuss the latter, e.g. in the devfs section, but the stuff above that section applies even to systems with device special files stored on the root file system. -- Guy Harris ( talk) 23:28, 16 December 2009 (UTC)
Article states that block devices are dangerous, what part I missed? Linux uses block devices, for example, it's the first time that I read that... — Preceding unsigned comment added by Sebelk ( talk • contribs) 16:34, 1 May 2013 (UTC)
In UNIX parlance, the distinction between character and block devices is that character devices expose the properties of the underlying hardware (e.g. they may disallow reads and writes if they are not aligned to the device block size), while block devices are buffered by the system. This is somewhat counter-intuitive as it leads to character devices necessitating that you read in whole blocks, while block devices will let you read a character at a time regardless of the block size.
The current description is, therefore, wrong, and so I’m going to update it. The reason for adding this comment on the Talk page is to dissuade people from changing it back without thinking. Ajhoughton ( talk) 09:49, 24 April 2014 (UTC)
Two standard types of device files exist; unfortunately their names are, for historical reasons, rather counter-intuitive, and explanations of the difference between the two are often incorrect as a result. [...] The character device for a hard disk, for example, will normally require that all reads and writes are aligned to block boundaries and most certainly will not let you read a single byte.
The caching will reorder the sequence of write operations, depriving the application of the ability to know the exact disk contents at any one instant in time.
The notion of "character special files"/"character devices" and "block special files"/"block devices" dates back at least to UNIX V6, and is implemented in many of the major Unix-like systems, including Linux and OS X and, I think, the current commercial UNIXes (Solaris, AIX, HP-UX), NetBSD, and OpenBSD. FreeBSD, however, has eliminated block devices.
Traditionally, file system I/O went through a buffer cache mechanism, and so did block special file I/O, so only devices capable of some approximation of random access had block special files (this included magnetic tapes, although the hardware for most tapes didn't support overwriting blocks, so, while you could do slow random-access reads, you had to do sequential writes).
"Character" special files just passed read, write and, in V7 and later, ioctl operations directly through to the driver. For disks, the seek offset had to be on a block boundary (looking at the source to physio(), if it wasn't on a block boundary, the lower 9 bits were treated as if they were 0), and the count would have to be an even number of words - as I remember, if it wasn't a multiple of the block size, 512, it would just not transfer the leftover bytes on a read, but I'm not sure what it'd do on a write. For tapes, the seek offset was ignored, and a block of the specified size would be read or written; I don't remember what happened on a read if the byte count was too small for the block on tape, but if it was too large, the read would return the actual block size on tape.
For non-disk and non-tape devices, there's typically only a character special file. Traditionally, disks and tapes had both types of files, and my OS X Mountain Lion machine has both block ("/dev/disk*") and character ("/dev/rdisk*") devices for disks, but the Linux kernel on my Ubuntu virtual machine appears to have only block special files for disks under /dev, and my FreeBSD 7.5 virtual machine has no block special files at all, only character special files, including for the disks. See section 9.4. "Block Devices (Are Gone)" of chapter 9 "Writing FreeBSD Device Drivers" of the FreeBSD Architecture Handbook.
Not all Unix-like systems have a traditional buffer cache, so the semantics of the disk block devices, if they exist, depend on the OS. For example, SunOS 4.x had a small buffer cache used for file system metadata that was not part of a file or directory's data, such as inodes and free block bitmaps, but the bulk of caching went through the page cache, which was a completely separate cache, indexed by file and offset within file, rather than by device and block number on the device as was done with the buffer cache. As I remember, the block special files used the buffer cache, not the page cache. On a system with only one buffer cache, I/O to a block special file would affect the same cache that the file system would use, but, on a system such as SunOS 4.x with two separate caches, I/O to a block special file wouldn't affect cached file data or directory data.
The notion of character special files is pretty much the same on all Unix-like systems, except for disks. Whether block devices even exist, whether disks offer block device interfaces, whether disks offer character device interfaces, and the way the block device interface to a disk works is, however, dependent on which system you're using. I think that, on the Unix-like systems where disks offer a character device interface, the behavior is the same - each read() or write() maps to a block-boundary multi-block read or write operation, perhaps with differences in what happens if the seek offset or byte count isn't a multiple of the sector size. Guy Harris ( talk) 00:17, 22 October 2014 (UTC)
holds true for Linux as well as Unix. That of course is assuming that the sg driver is representative for character device drivers in Linux but I'd be very surprised if that wasn't the case. 80.243.171.133 ( talk) 13:50, 21 February 2015 (UTC)In UNIX parlance, the distinction between character and block devices is that character devices expose the properties of the underlying hardware (e.g. they may disallow reads and writes if they are not aligned to the device block size), while block devices are buffered by the system. This is somewhat counter-intuitive as it leads to character devices necessitating that you read in whole blocks, while block devices will let you read a character at a time regardless of the block size.
I love the MS-DOS arcana (that's my kind of encyclopedia), but it was too heavy for a lead beginning "in Unix-like operating systems", so I thinned and demoted, with some text overlap. — MaxEnt 17:35, 28 April 2017 (UTC)
I personally would split out the content concerning device file systems. Device file systems also have one foot firmly planted in managing hardware change events, itself a huge and contentious area (for which the footnote on MS-DOS would be rather spartan).
Virtual file systems is its own little area of computer science, quite apart from the original "everything is a file" abstraction that originally motivated device files. The content here on dfs is relatively weak and probably won't much improve while surrounded by so much nitty-gritty otherness. — MaxEnt 18:17, 28 April 2017 (UTC)
I have some doubts about the Windows 9x entry. This has been added in an earlier revision of 2010-04-05 with the note I remember Windows having something like it too
and the added code also contains an invisible comment as seen in the cdplayer.exe program
.
Well, I checked the cdplayer.exe
binary from Windows 98 SE for any occurrences of the substring device
and only found the strings \Device\CdRom%d <%c:>
and GetDeviceCaps
. The second one is irrelevant and the first one would suggest an NT namespace-like path (although I don't understand what the <%c:>
suffix has to do there).
Based on this I'd guess the device access in Windows 9x could be similar to Windows NT, but I cannot find any references to verify this. Also, the Windows 9x wouldn't probably have an NT namespace but something similar might probably have existed there.
Anyone knowledgeable enough with the Windows 9x family who could verify and/or fix this information?
-- JITR ( talk) 23:35, 9 August 2017 (UTC)
Article starts talking about nodes without defining what they are. Should a separate article be written that defines node? Daniel.Cardenas ( talk) 22:08, 6 October 2017 (UTC)
This article doesn't have a Chinese version linked to it, and when I try to create it with the name "设备文件" I find the name occupied. The Chinese article
These two articles, bearing the same name (though in different languages), share some of the contents, and there are also differences, a lot of them.
I also find that both of the two versions are linked with same pages ( This article, in German is one of them), but the connection between the two of them seems to be lost.
How do you think I should deal with the problem? I have no trouble editing articles in either Chinese or English.
Linus Xu ( talk) 01:33, 22 April 2018 (UTC)
This is wrong. It was inherited from CP/M to which it was inherited from TOPS-10.-- Reciprocist ( talk) 11:42, 7 March 2019 (UTC)
This is the
talk page for discussing improvements to the
Device file article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||
|
![]() | The contents of the /dev/hda page were merged into Device file on 4 November 2010. For the contribution history and old versions of the redirected page, please see its history; for the discussion at that location, see its talk page. |
FreeBSD has done away with Block Devices. Some more should be written about this in the Character Device section. —Preceding unsigned comment added by 192.156.198.15 ( talk) 19:52, 5 January 2010 (UTC)
I'd like to suggest a re-write please. Perhaps based on sectioning information pertaining to Linux, Windows and BSD? For example, the Windows references are not clearly differentiated here. Notice that the third sentence follows a second sentence Windows reference. Does the word "They" in the third sentence refer to Windows systems, to Unix-Linux systems or to both? Maybe references to Windows differences should appear later in the article since the article points out that Windows borrowed the concepts from Unix? Clearly set off so that people can find the system they need described? — Preceding unsigned comment added by 70.253.70.197 ( talk) 01:08, 3 April 2012 (UTC)
The tone of voice in the devfs section is opinionated. The section is also out of place in its context. It only serves to confuse the reader, especially when the table below it makes clear that devfs is deprecated now. Gwrede ( talk) 09:50, 22 April 2009 (UTC)
There is another article by the name of Device name. (Which was made before this one) I was thinking about either merging it into this one (under the Device Files heading), or linking them with See Also links. Do you think the Device name article is significant enough to keep it separate, or should it be merged? I would probably completely replace the table under Device Files with the contents of Device name, as Device name has a lot more information. Otherwise the See Also links are trivial. -- NerdBoy1392 < Talk| Contribs> 23:44, 19 October 2008 (UTC)
The result of the move request was page moved to device file. Skomorokh 10:25, 27 December 2009 (UTC)
Device file system → device special file — This page mainly discusses the concept of a device special file, not the concept of a special file system that contains device special files It can continue to discuss the latter, e.g. in the devfs section, but the stuff above that section applies even to systems with device special files stored on the root file system. -- Guy Harris ( talk) 23:28, 16 December 2009 (UTC)
Article states that block devices are dangerous, what part I missed? Linux uses block devices, for example, it's the first time that I read that... — Preceding unsigned comment added by Sebelk ( talk • contribs) 16:34, 1 May 2013 (UTC)
In UNIX parlance, the distinction between character and block devices is that character devices expose the properties of the underlying hardware (e.g. they may disallow reads and writes if they are not aligned to the device block size), while block devices are buffered by the system. This is somewhat counter-intuitive as it leads to character devices necessitating that you read in whole blocks, while block devices will let you read a character at a time regardless of the block size.
The current description is, therefore, wrong, and so I’m going to update it. The reason for adding this comment on the Talk page is to dissuade people from changing it back without thinking. Ajhoughton ( talk) 09:49, 24 April 2014 (UTC)
Two standard types of device files exist; unfortunately their names are, for historical reasons, rather counter-intuitive, and explanations of the difference between the two are often incorrect as a result. [...] The character device for a hard disk, for example, will normally require that all reads and writes are aligned to block boundaries and most certainly will not let you read a single byte.
The caching will reorder the sequence of write operations, depriving the application of the ability to know the exact disk contents at any one instant in time.
The notion of "character special files"/"character devices" and "block special files"/"block devices" dates back at least to UNIX V6, and is implemented in many of the major Unix-like systems, including Linux and OS X and, I think, the current commercial UNIXes (Solaris, AIX, HP-UX), NetBSD, and OpenBSD. FreeBSD, however, has eliminated block devices.
Traditionally, file system I/O went through a buffer cache mechanism, and so did block special file I/O, so only devices capable of some approximation of random access had block special files (this included magnetic tapes, although the hardware for most tapes didn't support overwriting blocks, so, while you could do slow random-access reads, you had to do sequential writes).
"Character" special files just passed read, write and, in V7 and later, ioctl operations directly through to the driver. For disks, the seek offset had to be on a block boundary (looking at the source to physio(), if it wasn't on a block boundary, the lower 9 bits were treated as if they were 0), and the count would have to be an even number of words - as I remember, if it wasn't a multiple of the block size, 512, it would just not transfer the leftover bytes on a read, but I'm not sure what it'd do on a write. For tapes, the seek offset was ignored, and a block of the specified size would be read or written; I don't remember what happened on a read if the byte count was too small for the block on tape, but if it was too large, the read would return the actual block size on tape.
For non-disk and non-tape devices, there's typically only a character special file. Traditionally, disks and tapes had both types of files, and my OS X Mountain Lion machine has both block ("/dev/disk*") and character ("/dev/rdisk*") devices for disks, but the Linux kernel on my Ubuntu virtual machine appears to have only block special files for disks under /dev, and my FreeBSD 7.5 virtual machine has no block special files at all, only character special files, including for the disks. See section 9.4. "Block Devices (Are Gone)" of chapter 9 "Writing FreeBSD Device Drivers" of the FreeBSD Architecture Handbook.
Not all Unix-like systems have a traditional buffer cache, so the semantics of the disk block devices, if they exist, depend on the OS. For example, SunOS 4.x had a small buffer cache used for file system metadata that was not part of a file or directory's data, such as inodes and free block bitmaps, but the bulk of caching went through the page cache, which was a completely separate cache, indexed by file and offset within file, rather than by device and block number on the device as was done with the buffer cache. As I remember, the block special files used the buffer cache, not the page cache. On a system with only one buffer cache, I/O to a block special file would affect the same cache that the file system would use, but, on a system such as SunOS 4.x with two separate caches, I/O to a block special file wouldn't affect cached file data or directory data.
The notion of character special files is pretty much the same on all Unix-like systems, except for disks. Whether block devices even exist, whether disks offer block device interfaces, whether disks offer character device interfaces, and the way the block device interface to a disk works is, however, dependent on which system you're using. I think that, on the Unix-like systems where disks offer a character device interface, the behavior is the same - each read() or write() maps to a block-boundary multi-block read or write operation, perhaps with differences in what happens if the seek offset or byte count isn't a multiple of the sector size. Guy Harris ( talk) 00:17, 22 October 2014 (UTC)
holds true for Linux as well as Unix. That of course is assuming that the sg driver is representative for character device drivers in Linux but I'd be very surprised if that wasn't the case. 80.243.171.133 ( talk) 13:50, 21 February 2015 (UTC)In UNIX parlance, the distinction between character and block devices is that character devices expose the properties of the underlying hardware (e.g. they may disallow reads and writes if they are not aligned to the device block size), while block devices are buffered by the system. This is somewhat counter-intuitive as it leads to character devices necessitating that you read in whole blocks, while block devices will let you read a character at a time regardless of the block size.
I love the MS-DOS arcana (that's my kind of encyclopedia), but it was too heavy for a lead beginning "in Unix-like operating systems", so I thinned and demoted, with some text overlap. — MaxEnt 17:35, 28 April 2017 (UTC)
I personally would split out the content concerning device file systems. Device file systems also have one foot firmly planted in managing hardware change events, itself a huge and contentious area (for which the footnote on MS-DOS would be rather spartan).
Virtual file systems is its own little area of computer science, quite apart from the original "everything is a file" abstraction that originally motivated device files. The content here on dfs is relatively weak and probably won't much improve while surrounded by so much nitty-gritty otherness. — MaxEnt 18:17, 28 April 2017 (UTC)
I have some doubts about the Windows 9x entry. This has been added in an earlier revision of 2010-04-05 with the note I remember Windows having something like it too
and the added code also contains an invisible comment as seen in the cdplayer.exe program
.
Well, I checked the cdplayer.exe
binary from Windows 98 SE for any occurrences of the substring device
and only found the strings \Device\CdRom%d <%c:>
and GetDeviceCaps
. The second one is irrelevant and the first one would suggest an NT namespace-like path (although I don't understand what the <%c:>
suffix has to do there).
Based on this I'd guess the device access in Windows 9x could be similar to Windows NT, but I cannot find any references to verify this. Also, the Windows 9x wouldn't probably have an NT namespace but something similar might probably have existed there.
Anyone knowledgeable enough with the Windows 9x family who could verify and/or fix this information?
-- JITR ( talk) 23:35, 9 August 2017 (UTC)
Article starts talking about nodes without defining what they are. Should a separate article be written that defines node? Daniel.Cardenas ( talk) 22:08, 6 October 2017 (UTC)
This article doesn't have a Chinese version linked to it, and when I try to create it with the name "设备文件" I find the name occupied. The Chinese article
These two articles, bearing the same name (though in different languages), share some of the contents, and there are also differences, a lot of them.
I also find that both of the two versions are linked with same pages ( This article, in German is one of them), but the connection between the two of them seems to be lost.
How do you think I should deal with the problem? I have no trouble editing articles in either Chinese or English.
Linus Xu ( talk) 01:33, 22 April 2018 (UTC)
This is wrong. It was inherited from CP/M to which it was inherited from TOPS-10.-- Reciprocist ( talk) 11:42, 7 March 2019 (UTC)