Re: [ANNOUNCE] udev 0.1 release

[Oliver Neukum]

> If you are worried about this, don't reuse x:y.  Make them purely
> dynamic, and incrementing :)  Yes, this is a 2.7 thing, but will happen

Not enough numbers. Not even in a 32:32 major:minor split.

> eventually.  I need this framework in order to be able to do that, so
> one can't happen without the other...
>
> > It's worse, if you miss a 'remove' event. In that case you are
> > potentially permanently screwed.
>
> I don't want to ever miss events.

Surely, you don't want to miss them. Yet there are cases you are screwed.
Look at the hotplug spawning code and you'll see that it takes only one
kmalloc failling.

[..]
> Then it gets swapped back in.  There isn't anything I can do from
> userspace about this.  Hm, well I could pin the memory for the daemon,
> but that wouldn't be nice :)

That's exactly what you need to do. You can do this, if you change
the hotplugging notification to a pure pipe thing and lock the demon
into memory.  But then you have no advantage freom doing it in user
space, in fact you'll have the overhead of page tables for no benefit.

> Ok, if you are worried about these kinds of things, then use the
> in-kernel devfs.  I'm not going to dispute that userspace faults can
> happen.

Yes, in my oppinion putting such things into user space is stupid.
Your considerable talents would be better used to help Adam getting
his simplified devfs ready.

[..]
> > And yes, any scheme that handles device removal in user space has this
> > problem.
>
> True.  This is hard, let's go shopping...

Your attitude is admirably relaxed :-)

[..]
> > > Yes, if you lose a remove, things can get out of whack.  My goal is to
> > > not lose any.
> >
> > How? Or precisely, how can you guarantee it?
>
> I can guarantee nothing :)

Then you fail. Security without guarantee is no security.

> But I can do a lot to prevent losses.  A lot of people around here point
> to the old way PTX used to regenerate the device naming database on the
> fly.  We could do that by periodically scanning sysfs to make sure we
> are keeping /dev in sync with what the system has physically present.
> That's one way, I'm sure there are others.

Walking sysfs is a race condition by itself.
Don't get me started on that.

	Regards
		Oliver