Messages in this thread | | | Date | Tue, 10 Feb 2004 14:46:16 -0500 | From | Chris Friesen <> | Subject | Re: devfs vs udev, thoughts from a devfs user |
| |
Mike Bell wrote:
> Why does it make management easier to have no predictable name for a > device?
I believe this is a misconception.
Udev uses standard rules by default. If the end-user (or their distro) wants to add additional rules or override these rules, they can do that.
> I think the space savings are a pretty good reason alone. Add to that > the fact I think devfs would be a good idea even if it cost MORE > memory... You can mount a devfs on your RO root instead of needing to > mount a tmpfs on /dev and then run udev on that.
Don't you have to explicitly mount /dev as type devfs? How is this different than mounting it as tmpfs?
> A devfs gives > consistant names for devices in addition to the user's preferred > user-space dictated naming scheme.
Udev gives consistant names unless you explicitly override it.
> A devfs means even with dynamic > majors/minors, even if you have new hardware in your system, your /dev > at least has the devices it needs.
So does udev.
The real gain with devfs is that you don't need to have any userspace intervention to get /dev/ populated with a baseline set of device nodes. As long as the udev code is sufficiently robust and compact, I don't have a problem with needing a userspace daemon. Anyone that *really* cares about compactness (embedded people, for instance) is going to use a static /dev tree pruned down to the bare minimum. For everyone else, the overhead of having udev running should be unnoticeable.
Chris
-- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |