Hostility in plain sight

Posted Dec 18, 2012 21:26 UTC (Tue) by viro (subscriber, #7872)
In reply to: Hostility in plain sight by Cyberax
Parent article: The eudev project launches

Read it someday, would you? The logics around the removal (or non-removal) of directory trees in there is really nasty, and I'm not talking about the implementation - semantics from hell, no matter how you implement. For a long time it also had been a constant source of headache for fs/namei.c interfaces; took quite a while to get it more or less tolerable in that respect. In the form it went in, it had been amazingly bad. A lot of races is avoided these days *only* because it's serialized to hell and back. Besides, it's very unfriendly to containers. By design.

to post comments

Hostility in plain sight

Posted Dec 18, 2012 23:21 UTC (Tue) by HelloWorld (guest, #56129) [Link] (7 responses)

> Besides, it's very unfriendly to containers.
How does it affect containers?

Hostility in plain sight

Posted Dec 18, 2012 23:46 UTC (Tue) by viro (subscriber, #7872) [Link] (6 responses)

It's a single-tree filesystem; *any* container mounting it will see the same system-wide tree. And yes, sysfs suffers the same problem (and that's one of the reasons why sysfs sucks by design), but there's it's somewhat alleviated (at the price of rather gross hacks). devtmpfs simply exposes the same directory tree, no matter which container has mounted it.

It's less of an issue than for sysfs (there we have network interfaces exposed, which hurts a lot more) and the most immediate problem has an fs of its own (devpts), but it's going to cause trouble as soon as container folks get serious about per-container block device visibility, etc.

I'd chalk that up to "lousy design likely to cause PITA for kernel work". Note that the only reason the problem exists at all is that this thing has been put kernel-side. And yes, we can kill the single-tree part of that mess, but then we'll get another source of headache with deciding how to propagate creation/removal events.

And no, that's not the only problem with that sucker.

Hostility in plain sight

Posted Dec 18, 2012 23:55 UTC (Tue) by HelloWorld (guest, #56129) [Link]

Interesting, thank you.

Hostility in plain sight

Posted Dec 19, 2012 0:49 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

Oh, come on.

udev in containers is no better than devtmpfs. And besides, you can simply enumerate device nodes by going through all major/minor numbers and be done with it.

Real namespacing of kernel resources is required in any case. And not a window dressing you're proposing.

Hostility in plain sight

Posted Dec 19, 2012 1:25 UTC (Wed) by viro (subscriber, #7872) [Link] (3 responses)

Liar^WPolitician, do show me where the hell have I proposed any kind of "window dressing" regarding the interaction of udev or devtmpfs with containers. What I'm saying is that this thing (among its other problems) is going to be a source of PITA for container folks. And again, that's _not_ the only problem with it, lest you feel tempted to spin it that way.

Hostility in plain sight

Posted Dec 19, 2012 3:30 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

So you're admitting that udev/devtmpfs problems are not the result of devtmpfs/udev design, but are fundamental issues that would have to be tackled on.

Then why so much hate at devtmpfs? It's certainly not mandatory and it's useful for a wide class of users. Its source code is simple and short (yeah, it probably should be moved to /fs directory).

I kinda don't understand what criteria you're applying to 'good' vs. 'bad' design. I suspect it mostly is "if it makes someone's life easier than it's a bad design".

Hostility in plain sight

Posted Dec 19, 2012 4:36 UTC (Wed) by viro (subscriber, #7872) [Link] (1 responses)

You, sir, are a shameless liar.
1) devtmpfs problems include lousy semantics of directory removal. As I clearly said in this thread. The only "fundamental issue" here is that of crap not getting enough review.
2) devtmpfs problems include being extremely sloppy piece of code, both at the moment of inclusion and later, despite fixes of some of the problems [bet this shit will selectively quote up to the words "moment of inclusion" and claim that I admit it's good now]
3) sufficiently recent udev *does* make devtmpfs mandatory. As you very well know.

Hostility in plain sight

Posted Dec 19, 2012 5:05 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

>1) devtmpfs problems include lousy semantics of directory removal. As I clearly said in this thread. The only "fundamental issue" here is that of crap not getting enough review.
Doesn't matter for devtmpfs' purposes. Also, udev has lousy directory removal properties too.

>2) devtmpfs problems include being extremely sloppy piece of code, both at the moment of inclusion and later, despite fixes of some of the problems
What exactly is lousy there? It's a small 450-line skeleton FS. There's nothing complicated going on there.

Can you be even less specific?

> 3) sufficiently recent udev *does* make devtmpfs mandatory. As you very well know.
Ah, I've been using udev-172 on my devices. Looks like it's time to upgrade, I'm glad they're now relying on devtmpfs.

You can easily re-add support for new node creation in udev. But why bother? What exactly are you planning to achieve that way?