Re: udev and devfs - The final word

[Ian Kent]

On Thu, 8 Jan 2004, [koi8-r] "Andrey Borzenkov[koi8-r] "  wrote:

>
> >     4) devfs does provide a deamon that userspace programs can hook > into
> >        to listen to see what devices are being created or removed.
> >   Constraints:
> >     1) devfs forces the devfs naming policy into the kernel.  If you
> >        don't like this naming scheme, tough.
>
> kernel imposes naming scheme for exporting devices in sysfs. It is
> possible to get rid of devfs_name in kernel and use those names
> that must exist anyway to support udev as well. devfs has
> devfsd that can call whatever naming agent you like.

Yes. I'm having trouble finding justification for that statement as
well.

devfs appears to have almost no device name info within it.

>
> >     2) devfs does not follow the LSB device naming standard.
>
> it is user-space (devfsd) issue, not kernel space (devfs)

And there is heaps of device naming going on in devfsd. As is what people
seem to be recommending.

> > Oh yeah, and there are the insolvable race conditions with the devfs
> > implementation in the kernel, but I'm not going to talk about them > right
>
> I do not argue that current devfs implementation is ugly and racy. I
> just beg you to point at what makes those races "unsolvable".
>
> > now, sorry.  See the linux-kernel archives if you care about them (and
> > if you use devfs, you should care...)
>
> I do care. Searching archives for devfs mostly brings "everyone knows
> this is crap". That is why I kindly ask you to show real evidence that
> the problems it has are unsolvable.

Again I'm also unable to find descriptions of the 'unsolvable' races.

I wouldn't mind knowing what they are either. Anyone?

Ian


-
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/