Messages in this thread | | | From | Kay Sievers <> | Date | Fri, 1 May 2009 12:52:18 +0200 | Subject | Re: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs |
| |
On Fri, May 1, 2009 at 09:03, Andrew Morton <akpm@linux-foundation.org> wrote: > On Thu, 30 Apr 2009 23:55:27 -0700 Greg KH <greg@kroah.com> wrote: >> On Thu, Apr 30, 2009 at 11:43:12PM -0700, Andrew Morton wrote: >> > I don't understand why we need devfs2, really. What problems are >> > people having with teh existing design?
Bootup complexity. that you need a rather complex userspace, to get a system booted. Pretty annoying in the rescue case, where you might not have any working device node for a current disk. The static ones you may have on the rootfs image, now that we can have dynamic block device minors, may not work at all.
>> Boot speed, boot speed, boot speed.
>> Oh, and reduction in complexity in init scripts, and saving embedded >> systems a lot of effort to implement a dynamic
It makes it possible to run udev in the background at bootup, parallel to other things, instead of having a hard checkpoint to wait for, before you can continue to bring up the rest.
> > /dev properly (have you >> _seen_ what Android does to keep from having to ship udev? It's >> horrible...) > > Why can't they ship udev?
Not sure, seems they avoid GPL code, if they can. Besides that it's pretty slow to bootstrap /dev with stock udev. Most embedded systems use busybox's mdev here.
>> > Where is it determined that these subsystems create /dev subdirectories? >> > udev rules?
It should be defined in Documentation/devices.txt, and for some subsystems not mentioned there, it is only in the default udev rules set.
>> If so, do we need to henceforth keep devfs2 (sorry, I >> > can't resist) in sync with udev?
>> No, with this, udev rules can get simpler and remove these directory >> names, keeping them only in one place, preventing anything from getting >> out of sync.
During the last years, we synchronized all distros, and all ship exactly the same naming rules today besides a few distro-specific custom additions. So we have a common well defined setup today. With devtmpfs, the final decision is still in udev rules, like it is today, but with this, the kernel can pre-create a node, where udev will apply permissions/ownership to.
Future versions of udev will be able to follow the kernel provided device name hint, so drivers can provide a hint to userspace, without the need to drop udev rules. Existing udev rules would still overwrite the kernel-provided device node name hints. But this is all optional, devtmpfs enabled today works just fine with any old udev version, and udev should do the right thing on top.
> This assumes that devtmpfs is enabled in config, yes?
It's optional, yes.
> Does that means that we need two versions of udev out there, or can one > version be feasibly extended to handle both flavours of kernel?
No, udev works just fine with or without it. When udev receives the event, it looks if there is an already existing node, and if yes, it just applies the defined permissions/ownership to it. The final decisionss are still made in udev. All ownerships must be handled in uerspace anyway, there is no way for the kernel to assing group numbers.
It does not really change anything visible for the normal distros, besides that bootup can be made more efficient by running things in parallel, and that there will be a working and correct /dev in the rescue case.
For tiny, custom, embedded like setups, it might just work without any userspace help, or with something very simple compared what we need today.
Thanks, Kay -- 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/
| |