On 11/14/12 23:38, Robert Bonomi wrote:

it appears that FreeBSD, at least 8.0 and later:
    a) no longer uses 'raw' devices for anything
    b) no longer uses 'block' devices for anything
    c) randomly assigns device 'major' numbers
    d) doesn't use device 'minor' numbers for anything.
    e) as a result of c) and d), there is no way to
       establish 'device' physical characteristics
       from the 'node' information.

Is there a wizzard who can confirm/deny?

I'm not a wizard, I don't even count as a sorcerer's apprentice, but I can answer some of these. Firstly block devices were dropped when the unified VM cache came in as the semantics were incompatible. The Architecture Handbook has this rather terse entry about them:


As for major device numbers, in the original days of Unix the device table was just that - an array in the kernel indexed by major device number to get the device operation switch. (Actually there were two tables, one for cdevs and one for bdevs, but the principle's the same.) Device nodes in the file system were simple special inodes containing a (major, minor) pair and created statically by mknod. However, as more devices with different drivers came along it made sense to switch to the current model in which devices are discovered dynamically, both at boot and as they're plugged in and out. and /dev is a "magic" file system maintained by the kernel and daemons. It's a long time since I was very familiar with kernel internals, but I presume internally devices are now pointers and the device numbering fields returned by stat are simply for backwards compatibility.

As for the rest, you need someone more familiar with current kernel internals than I am - my main kernel hacking days ran from the Sixth Edition to BSD 4.2 and faded out as System V.4 came in. If no one turns up here, maybe try freebsd-hackers@

Or, if there's a better place to ask, can anyone point me there?

There are significant performance and 'addressability' issues when doing
i/o directly to 'fixed block' devices, especially 'write-once' media.`

The classical 'block' device type was a reliable indicator of 'fixed block'
behavior,  how does one make that determination today?

Is there any way to get 'classic' mag-tape behavior -- where, for example
a read(2) returned the lesser of the bytes in the block, and positioned
to the beginning of the next, regardless of whether the etire content of
the current block had been read ?`

I haven't seen a real mag tape drive in over a decade, so have no hope of commenting on that.

freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Reply via email to