Am Freitag, 19. Mai 2006 03:14 schrieb Goswin von Brederlow:
Hendrik Sattler [EMAIL PROTECTED] writes:
Am Donnerstag, 18. Mai 2006 21:53 schrieb Goswin von Brederlow:
But how do you detect when there is no device to be found to call the
function?
That's of absolutely no interest because
Hello,
On Tue, 16.05.2006 at 04:05:41 +, Brian M. Carlson [EMAIL PROTECTED]
wrote:
[ udev being, umm, not very nice ]
Need I say more?
yes: Please say *why* newer 2.6.x kernels actually do depend on udev
instead of hotplug.
Thank you!
Best,
--Toni++
--
To UNSUBSCRIBE, email to
Am Donnerstag 18 Mai 2006 11:25 schrieb Toni Mueller:
Hello,
On Tue, 16.05.2006 at 04:05:41 +, Brian M. Carlson
[EMAIL PROTECTED] wrote:
[ udev being, umm, not very nice ]
Need I say more?
yes: Please say *why* newer 2.6.x kernels actually do depend on udev
instead of hotplug.
On Wed, May 17, 2006 at 10:24:28PM +0200, Goswin von Brederlow wrote:
What timeout? With feedback you would know exactly when it is done and
wouldn't have to poll.
Quoting Linus:
: It really is very hard to accept the blocking behaviour.
:
: Some things can take a _loong_ time to be ready,
On Thu, May 18, 2006 at 11:25:46AM +0200, Toni Mueller wrote:
yes: Please say *why* newer 2.6.x kernels actually do depend on udev
instead of hotplug.
1. They do not depend on it at all. 2.6.x kernels work just fine with a
static /dev as long as you don't need dynamic device creation. There
On Thu, May 18, 2006 at 04:16:33PM +0200, Gabor Gombas wrote:
On Wed, May 17, 2006 at 10:24:28PM +0200, Goswin von Brederlow wrote:
Just like the kernel always did prior to udev.
You're missing a very important thing. This is _NOT_ a udev vs.
pre-udev question. This is a new kernel hotplug
Gabor Gombas [EMAIL PROTECTED] writes:
On Wed, May 17, 2006 at 10:24:28PM +0200, Goswin von Brederlow wrote:
What timeout? With feedback you would know exactly when it is done and
wouldn't have to poll.
Quoting Linus:
: It really is very hard to accept the blocking behaviour.
:
: Some
Toni Mueller [EMAIL PROTECTED] writes:
Hello,
On Tue, 16.05.2006 at 04:05:41 +, Brian M. Carlson [EMAIL PROTECTED]
wrote:
[ udev being, umm, not very nice ]
Need I say more?
yes: Please say *why* newer 2.6.x kernels actually do depend on udev
instead of hotplug.
Thank you!
Udev
On Thu, May 18, 2006 at 04:50:44PM +0200, Wouter Verhelst wrote:
Install udev on my system - things break randomly and unreproducibly,
due to race conditions all over the place.
This is quite in line with what I said about userspace not being ready
for hotplug. The kernel can send the events
On May 18, Gabor Gombas [EMAIL PROTECTED] wrote:
Actually, if you look at the hotplug .agent scripts you may find
artificial sleeps in some of them that's just seem to paper over the
race conditions you're talking about... What happens if you add the same
delays to the udev rules?
RUN rules
On Thu, May 18, 2006 at 05:01:53PM +0200, Goswin von Brederlow wrote:
Now the system randomly doesn't boot and instead of a 10 minute boot
time you have a 3 hour drive to reset the system and analyse that is
was just udev screwing you over.
Then introduce a timeout. Create
Wouter Verhelst [EMAIL PROTECTED] writes:
On Thu, May 18, 2006 at 04:16:33PM +0200, Gabor Gombas wrote:
On Wed, May 17, 2006 at 10:24:28PM +0200, Goswin von Brederlow wrote:
Just like the kernel always did prior to udev.
You're missing a very important thing. This is _NOT_ a udev vs.
Gabor Gombas [EMAIL PROTECTED] writes:
And that is what I consider broken. I know it is not going to change
but I pain for all the users (and myself) that will (and already have
been) get hit by problems caused by it.
Then why not start working on a solution? There are several distros
On May 18, Goswin von Brederlow [EMAIL PROTECTED] wrote:
The only other solution that keeps the asynchronisity is what Joey
suggested at the start: Instead of waiting/polling for udev events to
finish move the code into udev rules that get called asynchronously
when the devices appear. That
On Thu, May 18, 2006 at 07:16:00PM +0200, Goswin von Brederlow wrote:
That is because udev is slower so the window of the race condition
gets increased many many times. Without udev you don't have to wait
for the mknod call to complete.
I think you got the speed comparison wrong: udev does
On Thu, May 18, 2006 at 07:22:47PM +0200, Goswin von Brederlow wrote:
The only other solution that keeps the asynchronisity is what Joey
suggested at the start: Instead of waiting/polling for udev events to
finish move the code into udev rules that get called asynchronously
when the devices
On Thu, May 18, 2006 at 07:45:01PM +0200, Marco d'Itri wrote:
On May 18, Goswin von Brederlow [EMAIL PROTECTED] wrote:
The only other solution that keeps the asynchronisity is what Joey
suggested at the start: Instead of waiting/polling for udev events to
finish move the code into udev
Gabor Gombas [EMAIL PROTECTED] writes:
On Thu, May 18, 2006 at 07:16:00PM +0200, Goswin von Brederlow wrote:
That is because udev is slower so the window of the race condition
gets increased many many times. Without udev you don't have to wait
for the mknod call to complete.
I think you
On Thu, May 18, 2006 at 07:16:00PM +0200, Goswin von Brederlow wrote:
Wouter Verhelst [EMAIL PROTECTED] writes:
On Thu, May 18, 2006 at 04:16:33PM +0200, Gabor Gombas wrote:
On Wed, May 17, 2006 at 10:24:28PM +0200, Goswin von Brederlow wrote:
Just like the kernel always did prior to
On Thu, May 18, 2006 at 08:05:35PM +0200, Gabor Gombas wrote:
On Thu, May 18, 2006 at 07:16:00PM +0200, Goswin von Brederlow wrote:
That is because udev is slower so the window of the race condition
gets increased many many times. Without udev you don't have to wait
for the mknod call to
Gabor Gombas [EMAIL PROTECTED] writes:
On Thu, May 18, 2006 at 07:22:47PM +0200, Goswin von Brederlow wrote:
E.g. how do you convert startx into an udev rule so it can load
the mouse modules savely?
By the time the user types his/her password and starts startx the mouse
will be surely
Am Donnerstag, 18. Mai 2006 19:22 schrieb Goswin von Brederlow:
Because the only _solution_ with current userspace is to kill the
kernels hotplug design and go back to synchronous handling.
Another solution might be to dynamically attach to udev events. This is how
in-kernel async device
Hendrik Sattler [EMAIL PROTECTED] writes:
Am Donnerstag, 18. Mai 2006 19:22 schrieb Goswin von Brederlow:
Because the only _solution_ with current userspace is to kill the
kernels hotplug design and go back to synchronous handling.
Another solution might be to dynamically attach to udev
Am Donnerstag, 18. Mai 2006 21:53 schrieb Goswin von Brederlow:
Hendrik Sattler [EMAIL PROTECTED] writes:
Am Donnerstag, 18. Mai 2006 19:22 schrieb Goswin von Brederlow:
Because the only _solution_ with current userspace is to kill the
kernels hotplug design and go back to synchronous
Hendrik Sattler [EMAIL PROTECTED] writes:
Am Donnerstag, 18. Mai 2006 21:53 schrieb Goswin von Brederlow:
Hendrik Sattler [EMAIL PROTECTED] writes:
Am Donnerstag, 18. Mai 2006 19:22 schrieb Goswin von Brederlow:
Because the only _solution_ with current userspace is to kill the
kernels
On Wed, May 17, 2006 at 12:19:35AM +0200, Goswin von Brederlow wrote:
Matt Zimmerman [EMAIL PROTECTED] writes:
You don't need to wait for a particular event to be finished processing;
instead you should wait for the resource you actually need to become
available, e.g. a device node.
On May 17, Matt Zimmerman [EMAIL PROTECTED] wrote:
It may be possible to check that all pending udev events have completed.
It is possible to check the status of individual events by looking at the
queue, but it's not obvious why people would want to do this instead of
using RUN rules.
--
Matt Zimmerman [EMAIL PROTECTED] writes:
On Wed, May 17, 2006 at 12:19:35AM +0200, Goswin von Brederlow wrote:
Matt Zimmerman [EMAIL PROTECTED] writes:
You don't need to wait for a particular event to be finished processing;
instead you should wait for the resource you actually need to
The rest of the Linux distribution world is using udev with the current
semantics and has not crumbled. If you don't like the current semantics, I
understand, but that shouldn't stand in the way of its adoption.
--
- mdz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
Gabor Gombas [EMAIL PROTECTED] writes:
On Wed, May 17, 2006 at 10:44:21AM +0200, Goswin von Brederlow wrote:
Which is still stupid not to have in the kernel API as feedback from
the event manager and have insmod optionaly block.
For that to work you should make device discovery synchronous
On Wed, May 17, 2006 at 10:44:21AM +0200, Goswin von Brederlow wrote:
Which is still stupid not to have in the kernel API as feedback from
the event manager and have insmod optionaly block.
For that to work you should make device discovery synchronous everywhere
in the kernel. That would be a
Matt Zimmerman [EMAIL PROTECTED] writes:
On Mon, May 15, 2006 at 12:14:48PM +0200, Goswin von Brederlow wrote:
Matt Zimmerman [EMAIL PROTECTED] writes:
I don't see it as a general issue either; if you have problems of this
type,
you should report them to the bug tracking system so that
On Mon, May 15, 2006 at 12:14:48PM +0200, Goswin von Brederlow wrote:
Matt Zimmerman [EMAIL PROTECTED] writes:
I don't see it as a general issue either; if you have problems of this type,
you should report them to the bug tracking system so that they can be fixed.
Debian as an
Matt Zimmerman wrote:
On Mon, May 15, 2006 at 12:14:48PM +0200, Goswin von Brederlow wrote:
Matt Zimmerman [EMAIL PROTECTED] writes:
I don't see it as a general issue either; if you have problems of this type,
you should report them to the bug tracking system so that they can be fixed.
Debian
On Tue, 2006-05-16 at 08:52 +0600, Alexander E. Patrakov wrote:
Matt Zimmerman wrote:
You don't need to wait for a particular event to be finished processing;
instead you should wait for the resource you actually need to become
available, e.g. a device node.
It would be useful to add a
35 matches
Mail list logo
