Not logged in
Log in now
Create an account
Subscribe to LWN
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Little things that matter in language design
Hostility in plain sight
Posted Dec 18, 2012 23:46 UTC (Tue) by viro (subscriber, #7872)
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.
Posted Dec 18, 2012 23:55 UTC (Tue) by HelloWorld (guest, #56129)
Posted Dec 19, 2012 0:49 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
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.
Posted Dec 19, 2012 1:25 UTC (Wed) by viro (subscriber, #7872)
Posted Dec 19, 2012 3:30 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
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".
Posted Dec 19, 2012 4:36 UTC (Wed) by viro (subscriber, #7872)
Posted Dec 19, 2012 5:05 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
>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?
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds