Re: [bug] /etc/profile: line 30: /dev/null: Permission denied (Was: Re: [PATCH] Remove broken by design and by implementation devtmpfs maintenance disaster)

[Kay Sievers]

On Thu, Sep 17, 2009 at 22:26, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Thu, 17 Sep 2009, Kay Sievers wrote:

> That may be "not supported", but the point is, we want to make the kernel
> be as self-sufficient as possible, and the whole _point_ of this devtmpfs
> seemed to be to increase self-sufficiency rather than decrease it by
> requiring 'udev' to have run very very early.

Yes, that's the point. We could try to push the limit even higher and
try to run without udev. A few embedded and linux-on-cell-phone people
already asked for the same thing.

> If you have udev running really early, then what's the point of devtmpfs?
> You might as well just have udev and tmpfs.

It still simplifies the bootstrapping of an empty mounted /dev tmpfs,
and makes the node creation synchronous, unlike udev. It also makes
rescue very easy and reliable. It solves a bunch of problems, at least
for system-level privileged tasks, like module loading with immediate
device access after modprobe returns.

> So I suspect /dev/null and /dev/zero should be special - just make them
> have 0666 permissions. Because they really _are_ special, and no other
> permissions ever make sense for them.

That's true. I guess there are a few more devices that need special
permissions. We could make that happen, so people could probably run a
system without udev on top, at least in a controlled environment. For
distros it's not that interesting, they will need all the hotplug
handling, and all the stuff that plugs into udev's event mechanisms.
We only thought about bootup and root users for now, but that could be
changed, if it makes things easier.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/