Hostility in plain sight

Posted Dec 19, 2012 1:25 UTC (Wed) by viro (subscriber, #7872)
In reply to: Hostility in plain sight by Cyberax
Parent article: The eudev project launches

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.

to post comments

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?