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 in
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
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 synchro
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 u
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 disc
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 sur
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 c
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
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 t
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 int
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 device
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 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. T
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 distr
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 "ud
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 /etc/default/wait
On May 18, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> Actually, if you look at the hotplug .agent scripts you may find
> artificial "sleep"s 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
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
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.
>
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.
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
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. Ther
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,
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
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 t
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
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 syn
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 "unsubs
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 actua
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.
--
ci
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 no
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 tracki
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 usefu
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.
Debia
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 or
35 matches
Mail list logo
