Talk:Device mapper

dmraid, mdadm...

I hoped to find some information here about dmraid and a possible relation to mdadm. dmraid detects my SATA RAID array (RAID 1), but doesn't seem to offer any monitoring; unfortunately, no dmraid mentioned on the mdadm page, either... 82.141.22.162 (talk) 09:35, 7 April 2010 (UTC)

• In a few words, using dmraid ("fake" RAID) isn't advisable, as it brings zero benefits over using Linux's own software RAID. Even worse, with the oncoming advances features for RAID 1 in btrfs, only using btrfs' own internal RAID will be making sense — from the point of getting most out of the hardware. -- Dsimic (talk) 01:57, 30 September 2013 (UTC)

Device mapper is not a driver

The device mapper is not a driver; the fact that it lives under the drivers/ directory is not any evidence (it was probably just the most convenient place to put it). And the provided link is not an appropriate source anyway.

The edit comment says "Well, it isn't a *device* driver, but it is a kind of driver in the end". What other kind of drivers are there? The driver disambiguation page only lists one meaning. In the Linux kernel world, not every kernel module is called a "driver". The terminology may be less precise with the Windows kernel. -- intgr [talk] 00:22, 30 September 2013 (UTC)

• Hello there! I'm more than happy to discuss this, so we end up finding the correct classification... :)
  In case Linux kernel sources aren't a good enough evidence, I must add that Red Hat documentation also calls it a driver... Well, why are then md, loop, AoE or oprofile also within the drivers subdirectory, for example? They have nothing to do with accessing hardware directly, too — if we say that something called a driver must be doing that. Ok, we could call dm a framework, but what would then be AoE, for example? Something? :)
  Here's a nice slideshow which actually brings up the "are all drivers device drivers?" question: Introduction to Linux Drivers. Basically, a device driver should be something dealing directly with hardware, while plain driver should be a non-core Linux component providing something directly accessible to the userspace. Though, as something against that "rule", we have kvm outside the drivers directory, and within its separate virt directory... Could it really be that so many Linux kernel developers were sooo lazy to create a separate directory for plain drivers? :)
  Also, calling dm a module wouldn't be correct, as having something as a module only means it can be built as something that's separately loadable into the kernel — if you agree.
  How about calling dm a component? That's somehow neutral and surely acceptable — even the dm's project page calls it that way.
  Thoughts? I'm more than open for discussion. :) -- Dsimic (talk) 01:52, 30 September 2013 (UTC)
  • Went ahead and modified the article so it refers to dm as a component of the Linux kernel, so it's probably less confusing to people reading the article until we get a chance to discuss it further. -- Dsimic (talk) 11:23, 30 September 2013 (UTC)

These sources are much better than the one there currently. Here's also one by Milan Brož saying that device mapper is a "modular Linux 2.6 kernel driver" and "framework for constructing new block devices". You are correct that it's frequently called a driver.

But I still find this terminology contradictory -- almost every definition of "driver" I've seen talks about hardware/peripheral devices.

• Wiktionary: A program that acts as an interface between an application and hardware, written specifically for the device it controls.
• FOLDOC: <operating system> {device driver}. device driver: <operating system> {Software} to control a hardware component or {peripheral} device of a computer such as a {magnetic disk}, {magnetic tape} or printer.
• Jargon file: In device driver, code designed to handle a particular peripheral device such as a magnetic disk or tape unit.
• WordNet: a program that determines how a computer will communicate with a peripheral device [syn: {driver}, {device driver}]
• Oxford: a program that controls the operation of a device such as a printer or scanner.

I believe we shouldn't use the word "driver" if it conflicts with most definitions. I think "framework" is the most appropriate term to use, because usually dm itself doesn't directly provide (virtual) device nodes to user space, but they are created via other subsystems like LVM2, dm-crypt/cryptsetup, TrueCrypt etc (which are based on the device mapper framework).

As for the word "component" -- I find that it's a noise word -- it doesn't actually help explain anything, you could call pretty much anything a component. Compare:

• device mapper is a Linux kernel component which provides a generic framework for mapping one block device onto another
• device mapper is a Linux kernel framework for mapping one block device onto another

I'd say the 2nd one is better because it's more concise.

As for the rest: AoE is first and foremost a network protocol, but I don't know what to call the Linux kernel implementation. Ditto loop/md/oprofile. They're certainly not frameworks in the way that device mapper is. But I don't think we have to solve that question to arrive at a consensus for device mapper. -- intgr [talk] 14:33, 30 September 2013 (UTC)

You're totally right about the widespread association between drivers and direct control of hardware devices, and the high potential for confusion if it's used for something else. Just a small addition regarding who provides device nodes for the dm's virtual devices — their creation is actually performed by dm, but in most cases is initiated by someone alse, like LVM2 for example. Of course, actual logic behind a virtual device is in many cases outside dm, but again sometimes it's within it — like in case of the striped or mirror mapping targets.

I couldn't agree more that component is a real buzzword — but then again, framework is also some kind of a widespread noise word... After spending some time thinking, producing and discarding a few more elaborate sentences, I ended up concluding the shortest one you proposed fits best — slightly expanded:

The device mapper is a Linux kernel framework for mapping block devices onto higher-level virtual block devices.

Are you finding that good enough and acceptable, please? Its main benefit is making early the distinction between real and virtual block devices.

Also, as a newcomer, I'm really glad Wikipedia sparks debates like this about such relatively insignifficant matters — what means people really care about the correctness and clarity. :) -- Dsimic (talk) 16:37, 30 September 2013 (UTC)

Yeah, I think that's very good. I find that "software framework" still is a fairly technical term that distinguishes the software from a library. -- intgr [talk] 16:53, 30 September 2013 (UTC)

Great, we're on the same page! Went ahead and edited the article. -- Dsimic (talk) 17:09, 30 September 2013 (UTC)