devfsd
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?
Quoted 2 lines · 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
Quoted 5 lines · Christoph Hellwig
Quoted 2 lines · 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-----
Quoted 6 lines · Christoph Hellwig
Quoted 2 lines · 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,
Signature · 1 line
Martin Schlemmer
Quoted 4 lines · Martin Schlemmer
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:
Quoted 8 lines · Martin Schlemmer
Quoted 4 lines
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?
Quoted 8 lines
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
Quoted 7 lines · Oliver Neukum
Quoted 5 lines
Quoted 2 lines
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.
Quoted 5 lines
Quoted 3 lines
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.
Quoted 1 line
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..