On Tue, Oct 18 2022 at 3:19P -0400, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Tue, Oct 18, 2022 at 11:54 AM Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > But no, we absolutely do *not* want to emulate that particular horror > > anywhere else. > > Side note: if DM people go "Hmm, a lot of our management really does > have the exact same issues as 'mount()' and friends, and doing the > same things as mount does with the whole string interface and logging > sounds like a good idea", I want to nip that in the bud. > > It's most definitely *not* a good idea. The mount thing is nasty, it's > just that we've always had the odd string interface, and it's just > grown from "const void *data" to be a whole complicated set of context > handling. > > So don't even think about duplicating that thing. > > Now, if some "inspired" person then thinks that instead of duplicating > it, you really would want to do device mapper *as* a filesystem and > actually using the fsconfig() model directly and natively, that is at > least conceptually not necessarily wrong. At what point does a > "translate disk blocks and munge contents" turn from "map devices into > other devices" to a "map devices into a filesystem"? We've had loop > devices forever, and they already show how filesystems and block > devices can be a mixed concept. > > And no, I'm not seriously suggesting that as a "do this instead". > > I'm just saying that from an interface standpoint, we _do_ have an > interface that is kind of doing this, and that is already an area > where a lot of people think there is a lot of commonalities (ie a > number of filesystems end up doing their own device mapping > internally, and people used to say "layering violation - please use dm > for that" before they got used/resigned to it because the filesystem > people really wanted to control the mapping). > > In the absence of that kind of unification, just use 'errno'. Mikulas touches on why why using errno isn't useful for DM. And for DM's device stacking it is hard to know which error spewed to dmesg (via DMERR, DMCRIT, DMINFO, etc) is relevant to a particular admin interface issuing the DM ioctl. So the idea to send the (hopefully useful) error string back up to the relevant userspace consumer was one task that seemed needed (based on Milan Broz's various complaints against DM.. which sprang from your regular remainder that DM's version numbers are broken and need to be removed/replaced). Making DM errors more useful to the endpoints causing them was dealt with head-on with a couple small changes in this pull request. I didn't think sending useful error strings to userspace was such a contested design point. All said, we'll have a look at dealing with your suggested fsconfig unification (but it seems really awkward on the surface, maybe we can at least distill out some subset that is common). Mike
