Hostility in plain sight

Posted Dec 19, 2012 0:49 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
In reply to: Hostility in plain sight by viro
Parent article: The eudev project launches

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.

to post comments

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?