public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Ihar 'Philips' Filipau" <filia@softhome.net>
To: Greg KH <greg@kroah.com>
Cc: Linux Kernel ML <linux-kernel@vger.kernel.org>
Subject: Re: udev is too slow creating devices
Date: Sat, 18 Sep 2004 21:25:56 +0200	[thread overview]
Message-ID: <414C8BC4.30303@softhome.net> (raw)

> The fact that a static /dev keeps these race conditions from showing up
> as often as they really are there is no reason to keep trying to rely on
> old, undefined behaviour :)

   [ I'm late to discussion, and do not have much time at all.
   Just observation from aside by driver writer and OS builder. ]

   You really do not solve problem - problem as I see it - but just move 
it around.

   When I did first release of device driver for some obscure device, I 
used to wait in init script for "touch /dev/whatever" to be Ok. My 
device was ok with dumb open()/close() sequence.

   What I was really missing - is a way to tell user space that not only 
driver loaded Ok, but that device was found, diagnosed and upped Ok. 
Diagnostics was taking time - that's why I tryed to do it async. While 
device does some inernal spinning, I can load up other drivers.

   I haven't found any reasonable solution. module_init() is locking 
everything - I cannot load any other module, while one module is 
loading. But from user space point of view this is the only way to 
return error from device driver.

   IOW, mapping my experience to this discussion, we need to have a way 
for user space to wait for discover process to end. After all user space 
knows better than enyone in kernel what to expect from loaded driver.

   We are not talking about hot-plug and preloading of modules. We are 
talking more about the case where system cannot go on without requested 
device & its device node. We need a way for modprobe to be able to wait 
for driver initialization phases (we do not have them - make it sense to 
have them?): driver initialization, device discovery, device 
initialization, device node ready. So then user space will be able to 
wait for driver to reach any of given phases. If init script needs 
/dev/sda1 and after all phases completed Ok we failed to locate it - it 
can mean only one thing - /dev/sda1 is not here. Since modprobe will 
wait - it will mean that we will be able to return error, if any. IMHO 
that what need to be implemented. Polling is crappy solution: we do not 
need to poll for something we can reliably find out.

   We have all info in kernel in drivers - we need a way to give it back 
to user space for both play nice with each other.

   My 0.02 Euro.

             reply	other threads:[~2004-09-18 19:26 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-18 19:25 Ihar 'Philips' Filipau [this message]
2004-09-18 21:24 ` udev is too slow creating devices Greg KH
  -- strict thread matches above, loose matches on Subject: below --
2004-09-18 19:44 Ihar 'Philips' Filipau
2004-09-18 20:37 ` Marc Ballarin
2004-09-18 21:30 ` Greg KH
2004-09-19  0:06   ` Ihar 'Philips' Filipau
2004-09-19  0:41     ` Greg KH
2004-09-19  8:18       ` Ihar 'Philips' Filipau
2004-09-20  4:19         ` Greg KH
2004-09-19  4:38 ` Benjamin Herrenschmidt
2004-09-19  8:27   ` Ihar 'Philips' Filipau
2004-09-19 11:53     ` Alexander E. Patrakov
2004-09-19 17:32       ` Greg KH
2004-09-19 18:43         ` Grzegorz Kulewski
2004-09-20  4:11           ` Greg KH
2004-09-20 10:52             ` Jon Masters
2004-09-19 12:00     ` Marc Ballarin
2004-09-19 14:25       ` Ihar 'Philips' Filipau
2004-09-19 15:14         ` Marc Ballarin
2004-09-19 16:00           ` Alexander E. Patrakov
2004-09-19 17:11             ` Marc Ballarin
2004-09-19 17:30             ` Greg KH
2004-09-20  2:29               ` Alexander E. Patrakov
2004-09-20 16:17                 ` Giacomo A. Catenazzi
2004-09-29 23:38               ` Randy.Dunlap
2004-09-29 23:53                 ` Greg KH
2004-09-19 19:40           ` Ihar 'Philips' Filipau
2004-09-20  0:05             ` Kyle Moffett
2004-09-20  4:06             ` Greg KH
2004-09-20  8:54             ` Marc Ballarin
2004-09-20  0:03         ` Benjamin Herrenschmidt
     [not found] <http://lkml.org/lkml/2004/9/15/119@localhost.localdomain>
2004-09-15 14:26 ` Michael Thonke
     [not found] <http://lkml.org/lkml/2004/9/14/316@localhost.localdomain>
2004-09-14 20:30 ` Michael Thonke
2004-09-14 18:33 Giacomo A. Catenazzi
2004-09-14 18:42 ` Greg KH
2004-09-14 19:21 ` Chris Meadors
2004-09-14 19:40 ` Chris Friesen
2004-09-14 19:52   ` Greg KH
2004-09-14 20:00     ` Chris Friesen
2004-09-14 20:43     ` Giacomo A. Catenazzi
2004-09-14 21:35       ` Greg KH
2004-09-14 21:45         ` Marco d'Itri
2004-09-14 21:51           ` Greg KH
2004-09-14 22:47             ` Andrea Arcangeli
2004-09-14 23:04               ` Greg KH
2004-09-14 23:20                 ` Andrea Arcangeli
2004-09-14 23:34                   ` Gianni Tedesco
2004-09-14 23:58                     ` Andrea Arcangeli
2004-09-15 16:15                   ` Greg KH
2004-09-15 19:21                     ` Andrea Arcangeli
2004-09-15 22:09                       ` Chris Friesen
2004-09-15 22:15                         ` Andrea Arcangeli
2004-09-15 22:25                           ` Greg KH
2004-09-15 22:23                       ` Greg KH
2004-09-15 22:46                         ` Andrea Arcangeli
2004-09-15 13:55                 ` Giacomo A. Catenazzi
2004-09-15 14:36                   ` Ian Campbell
2004-09-15 15:20                     ` Tonnerre
2004-09-15 15:45                       ` Giacomo A. Catenazzi
2004-09-15 16:12                         ` Greg KH
2004-09-15 16:51                         ` Marc Ballarin
2004-09-15 18:00                           ` Greg KH
2004-09-19 16:51                             ` Jon Masters
2004-09-19 18:53                             ` Andreas Jellinghaus
2004-09-20  2:16                               ` Alexander E. Patrakov
2004-09-17  8:06                           ` Alexander E. Patrakov
2004-09-15 16:11                     ` Greg KH
2004-09-15 16:09                   ` Greg KH
2004-09-17  7:48             ` Alexander E. Patrakov
2004-09-14 22:03       ` Marc Ballarin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=414C8BC4.30303@softhome.net \
    --to=filia@softhome.net \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox