Why is devfsd still tagged as EXPERIMENTAL even in 2.6.0-test1 ? Is
there something wrong with it, or has it just not been changed?
On Tue, Jul 15, 2003 at 04:46:10PM -0500, Ro0tSiEgE LKML wrote:
> Why is devfsd still tagged as EXPERIMENTAL even in 2.6.0-test1 ? Is
> there something wrong with it, or has it just not been changed?
It's still there because we don't have a BROKEN tag.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 17 July 2003 17:56, Christoph Hellwig wrote:
> On Tue, Jul 15, 2003 at 04:46:10PM -0500, Ro0tSiEgE LKML wrote:
> > Why is devfsd still tagged as EXPERIMENTAL even in 2.6.0-test1 ? Is
> > there something wrong with it, or has it just not been changed?
>
> It's still there because we don't have a BROKEN tag.
Hm, should we introduce a BROKEN tag? (I'm not kidding. :) )
Because in a development tree, many things are known broken
and with this tag we may reduce the same bug-reports on
this list over and over again.
- --
Regards Michael Buesch
http://www.8ung.at/tuxsoft
Penguin on this machine: Linux 2.4.21 - i386
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE/FtEuoxoigfggmSgRAvvxAJ4oeM9wSBYh9zSMESK90bFR+JfLXgCfWiDU
BZdHfen1MsXcNv6OicXSr9w=
=wrz0
-----END PGP SIGNATURE-----
On Thu, 2003-07-17 at 17:56, Christoph Hellwig wrote:
> On Tue, Jul 15, 2003 at 04:46:10PM -0500, Ro0tSiEgE LKML wrote:
> > Why is devfsd still tagged as EXPERIMENTAL even in 2.6.0-test1 ? Is
> > there something wrong with it, or has it just not been changed?
>
> It's still there because we don't have a BROKEN tag.
>
Apart from obvious/known inefficiencies, it works fine over here :P
Any way, if you are serious, what make you consider it broken (no,
not talking about personal preferences/phobias 8)
Cheers,
--
Martin Schlemmer
On Fri, Jul 18, 2003 at 07:57:24AM +0200, Martin Schlemmer wrote:
> Apart from obvious/known inefficiencies, it works fine over here :P
>
> Any way, if you are serious, what make you consider it broken (no,
> not talking about personal preferences/phobias 8)
There's unsolvable design issues in the way devfsd communication works
(with the last two patches the holes are closed as much as possible)
and it's fundamentally flawed by putting device name policy into
the kernel. And then there's of course certain implementation quality
issues...
We have udev now which solves what devfs tried to solve without that
issues so people should switch to that ASAP. That doesn't mean we
can simply rip it out because people started to rely on the non-standard
device names, but it's use is pretty much discouraged in 2.6.
Am Freitag, 18. Juli 2003 09:44 schrieb Christoph Hellwig:
> On Fri, Jul 18, 2003 at 07:57:24AM +0200, Martin Schlemmer wrote:
> > Apart from obvious/known inefficiencies, it works fine over here :P
> >
> > Any way, if you are serious, what make you consider it broken (no,
> > not talking about personal preferences/phobias 8)
>
> There's unsolvable design issues in the way devfsd communication works
> (with the last two patches the holes are closed as much as possible)
Could you elaborate?
> and it's fundamentally flawed by putting device name policy into
> the kernel. And then there's of course certain implementation quality
> issues...
>
> We have udev now which solves what devfs tried to solve without that
> issues so people should switch to that ASAP. That doesn't mean we
> can simply rip it out because people started to rely on the non-standard
> device names, but it's use is pretty much discouraged in 2.6.
How does udev avoid these complications?
If udev doesn't have those issues, why can't they be fixed for devfsd?
Regards
Oliver
On Fri, Jul 18, 2003 at 09:52:33AM +0200, Oliver Neukum wrote:
> > > Any way, if you are serious, what make you consider it broken (no,
> > > not talking about personal preferences/phobias 8)
> >
> > There's unsolvable design issues in the way devfsd communication works
> > (with the last two patches the holes are closed as much as possible)
>
> Could you elaborate?
lookup is called with i_sem on parent, devfs calls up to devfsd in
lookup which might again do operation that would block on the same
i_sem. To avoid the deadlock we have to drop i_sem somewhere which
always introduces races. In 2.4 and earlier 2.5 theses races where
huge and easily exploitable at least with the O(1) scheduler. In
current 2.5 they're much smaller so you usually don't trip them but
they;re not going away as long as we keep the stateful devfsd design.
> > issues so people should switch to that ASAP. That doesn't mean we
> > can simply rip it out because people started to rely on the non-standard
> > device names, but it's use is pretty much discouraged in 2.6.
>
> How does udev avoid these complications?
udev is a hotplug upcall, not a stateful deamon.
> If udev doesn't have those issues, why can't they be fixed for devfsd?
Not without changing it to a stateless design, i.e. recreating something
resembling udev..