0

As I'm looking through libdevmapper.h for clues on how to properly use device mapper ioctls (or potentially use libdevmapper instead), I'm confused as to why there is code in here for creating/managing a tree and hash table.

If libdevmapper serves to provide an interface to the underlying device mapper ioctls, then what's the motivation for including data structures in here? Furthermore, if the kernel already has data structures to manage all of the device mappings, it seems any abstracted library-level data structures would be a cached version of the real information at best.

Keep in mind that I'm new to device mapper, kernel code, and system calls. What am I missing here?

1

This is a very general answer—I confess to having not even read that header file. (If you want to ask detailed, code questions about it, Stack Overflow is the right place.)

What you appear to have missed is that data structures are how programs (and even separate parts of the same program) communicate. Each side of that communication needs to understand the data structure, or else the message is unintelligible.

So, for example, the kernel has a definition of struct stat somewhere, in some header. Your program also has one, from some different header provided by glibc (though likely it's been copied from the kernel one). When you use the stat syscall to get information on a file, you pass the kernel the address of a struct stat. The kernel fills in the information in that data structure. Then your program reads out the information. Your program communicated with the kernel using a data structure.

Another example, if you then pass that struct stat * to another function in your program (say, one responsible for displaying it), then your program has communicated between two parts of itself using a data structure.

So the tree and hash table implementations in libdevmapper, and in general the data structures in any kernel feature library header, are going to serve one (or more) of a few purposes:

  1. They're how the library communicates with the kernel.
  2. They're how the library communicates with your program.
  3. They're something the library's developers think your program will find useful (e.g., to keep track of devmapper state) and they figure it's small enough and/or closely related enough to include without being bloat.
  • thank you for taking the time to write out a (admittedly needed) rudimentary answer. I think this is one of those 'can't see the forest through the trees' days for me. – Zomp May 5 '17 at 19:18
  • It's good to realize the assumptions that we impose on things. For me, I have always separated "data structures" from "language encapsulation constructs," where data structures are specific methods of arranging data to achieve certain performance or behavior (tree, hash table, list, etc). It seems your point was simply to use a base-case example (with plain structs) to drive the point. Is that correct? – Zomp May 5 '17 at 19:25
  • @Zomp "data structure" is definitely a broader concept than "C struct". But yeah, I picked struct stat because it's fairly simple and surely familiar to all Unix programmers, even to many sysadmins. And it's simplicity makes it really obvious how it's being used to communicate with the kernel. – derobert May 5 '17 at 21:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.