Talk:Device file

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Software / Hardware (Rated Start-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Software (marked as Mid-importance).
Taskforce icon
This article is supported by Computer hardware task force (marked as Mid-importance).
 

Character Devices can be hard drives[edit]

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)

Clarification Needed[edit]

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)

Remove the devfs section?[edit]

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)

Also, devfsd has its own page and this content should be merged with it and the devfs link should point to devfsd 91.58.158.56 (talk) 05:43, 8 May 2014 (UTC)

Merger proposal[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Device name was merged into the Device files section of Device file system. --NerdBoy1392 18:18, 13 January 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 above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.


Requested move[edit]

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the move request was page moved to device file.  Skomorokh  10:25, 27 December 2009 (UTC)


Device file systemdevice 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)

Note also that with "devtmpfs" (and with udev in general?), the file system in which the special files reside is just an instance of tmpfs, not a special devfs. Guy Harris (talk) 23:32, 16 December 2009 (UTC)
  • I agree that main topic should be the Unix device file, because the file system is just the most recent implementation trend. And the article is correctly structured along these lines. But device file is much more common in books than device special file [1]. Pcap ping 00:35, 24 December 2009 (UTC)
OK, how about Device file systemdevice file, with device special file redirecting to device file? Guy Harris (talk) 20:05, 25 December 2009 (UTC)
That's what I was suggesting. Pcap ping 20:19, 25 December 2009 (UTC)
The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Block devices dangerous????[edit]

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 (talkcontribs) 16:34, 1 May 2013 (UTC)

Character Devices and Block Devices[edit]

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)

Hello there! Well, somehow you've got it quite wrong, let me quote one part of the content introduced by your edit:

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.

How can you have a character device for a HDD? Character and block devices got their names primarily by the amounts of data that's handled at a time by the underlying hardware device, and HDDs—​as an example—​internally operate with blocks of 512 bytes, or more recently with 4 KB sectors. At the same time, block devices provide permanent data storage and they're seekable, while character devices provide only "one time" actions and no data gets buffered. Thus, their names aren't counter-intuitive. See also this explanation, for example.
In a few words, your edit is quite misleading and I'll revert it, while adding one or two references to back the previosly present content. — Dsimic (talk | contribs) 01:21, 25 April 2014 (UTC)
No, I haven't got it wrong (it would be a surprise if I did, because I'm an expert in this area). The original article was wrong, which is why I edited it, and you're wrong too. That's why I wrote the explanation on the talk page, in the hope that someone might read it and not just immediately revert the change. It's very common to have a character device for a hard disk (for instance, on Mac OS X, the device "/dev/rdisk0" is the character device, while the device "/dev/disk0" is the block device). And you'll also note the comment about FreeBSD removing the disk block devices because they're dangerous, which means that the only disk devices on FreeBSD are character devices.
Nor is your claim that character devices provide only "one time" actions accurate. Some character devices are seekable (and SUSv4, which I referred to, is quite clear about that; IIRC it explicitly states that character devices other than terminal devices may be seekable). The only distinction is that block devices are buffered and don't expose hardware behaviour (like the underlying block size), whereas character devices are unbuffered and do expose hardware behaviour.
So, "in a few words", your revert is incorrect, your claims are incorrect, and I'm going to change it back again. Ajhoughton (talk) 20:25, 25 April 2014 (UTC)
The fact that BSDs treat them differently isn't the reason to present that as the only interpretation of character vs. block device meaning, while the old content of the article covers both interpretations. I'm not going to argue with you, and even less to go into edit warring. Feel free to revert and leave it for other editors to weigh in.
By the way, just have a look at this quote from the "block devices are bad" explanation:

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.

Isn't that what write barriers are there for? Sure, it's much simpler to ditch buffering than to implement write barriers. — Dsimic (talk | contribs) 02:38, 26 April 2014 (UTC)
It isn't that “BSDs treat them differently”, it’s that the name “character special file” comes from UNIX, so what is relevant here is what the Single UNIX Specification says, which unsurprisingly corresponds with the behaviour and documentation of System V and BSD UNIXen. Linux may very well be different — but Linux is not UNIX, and the distinction between character and block devices is not really present on other systems.
As for the comment from the FreeBSD documentation, you're right that write barriers improve matters for users of block devices, but they don't solve the problem of other software using character devices at the same time that you're using block devices to access the same underlying hardware. Ajhoughton (talk) 16:47, 29 April 2014 (UTC)
Well, Linux is different and it's here running on numerous computers and whatnot, so describing its behavior as well should be required in order for WP:NPOV to be maintained; the article isn't strictly only about device files in certified Unices. — Dsimic (talk | contribs) 17:45, 29 April 2014 (UTC)