Re: udev is too slow creating devices

From: Ihar 'Philips' Filipau (filia_at_softhome.net)
Date: 09/19/04

  • Next message: Tuomas Heino: "vfs hacking q: implementing "sectorfs" - hints?" 
    Date:	Sun, 19 Sep 2004 21:40:09 +0200
To: Marc Ballarin <Ballarin.Marc@gmx.de>

    Marc Ballarin wrote:
    > On Sun, 19 Sep 2004 16:25:51 +0200
    > Ihar 'Philips' Filipau <filia@softhome.net> wrote:
    >
    >
    >> Well, can then anyone explain by which mean (black magic?) kernel
    >>mounts root file system? block device might appear any time, file system
    >>might take ages to load.
    >
    >
    > The kernel doesn't use /dev.

       True. But udev together with new loadable modules model was
    advertised as a /right/ replacement for devfs,

    > Why do you think mounting the root device is such a "frail" process?
    > The kernel blindly ties all known filesystem on the specified device.
    > If the user specifies a wrong root device, or the device is broken or the
    > filesystem corrupted or unknown the kernel will panic.
    > The reason this is so is, that nothing else can be done. Userspace,
    > however, has more possibilities.
    >

       You are right - kernel doesn't know.
       It is driver knows, It is user of driver who does know it too.

    >
    >> People, you must learn doing abstractions carefully. If device is
    >>hard-wired - user *will* expect (as kernel itself does) that it is
    >>available all the time after modprobe'ing driver.
    >
    >
    > It is available as long as the device node is present. udev tells you (in
    > dev.d) when this is the case. If the device is hardwired (from a user's
    > point of view) the device node will be created early dring boot-up. If
    > this happens, udev will notify the scripts in dev.d.
    >
    > Instead of:
    > modprobe ide-cd && mount /dev/hdc /mnt/cdrom
    > in /etc/init.d/your-script
    >
    > you would now do:
    > if [ ACTION="add" ] && [ DEVNAME="/dev/hdc" ]; then
    > mount /dev/hdc /mnt/cdrom
    > fi
    > in /etc/dev.d/default/your-script.dev

       Well, go to /etc/rc.d and try to integrate that with rest of system.
       The only right way of handling of such stuff I know - is FSM.
       Implementing FSMs in shell scripts - last thing I ever wanted. And I
    still cannot get how you are going to safely serialize /etc/dev.d/
    callbacks against /etc/rc.d/ without polling.

    >
    > This is even more reliable than the first solution on a static /dev,
    > since loading the driver might fail at any point *after* modprobe
    > returns.

       Untrue. Driver if something fails have a chance to return error from
    module_init() function, which will be passed to modprobe and then to callee.

    > For example, modprobe ide-cd will succeed even when no CD-ROMs are
    > present. The old script would break in this case, the new one wouldn't be
    > called at all.
    >

       You are wrong. Hardware driver must fail, when hardware is not
    present/not detected. Simple as that.
       If ide-cd doesn't do that - it needs to be fixed.

    > Error reporting is very difficult. How should the kernel know what the
    > driver is supposed to do?

       Yes. Driver is not loaded without need. Kernel doesn't need driver -
    user need it to accomplish specific task.
       User knows what driver is meant for, especially when it loads it
    manually.
       If user will be told when driver is ready - user can verify that
    hardware in question is present.

    > Obvious errors likes Oopses or I/O errors *could* be reported by hotplug.
    > (ACTION="error", DEVNAME="module-name" ???)
    > Anything else is impossible.
    >
    > You just have to adopt your approach to device handling. Currently you
    > *assume* that after a succesfull modprobe the device nodes are available
    > (this was never true, however).
    > With hotplug/udev you *know* that the device node is available when your
    > script in dev.d is called with the appropriate environment variables.
    >

       What about scripts outside of /etc/dev.d/?

       If you ever mantained /etc/rc.d/rc - you will understand what I mean.
    Splitting system boot-up procedure will have some funny consequences.
    Debugging will be left as an execise for end-users. Running once fsck
    simultaneously on several partitions will cool your temper down.

       Again. FSM is no way to go for shell scripts. And shell scripts is
    what is used to manage system. Even /etc/dev.d/ scripts - are shell
    scripts, after all.

    P.S. If you will add errors to /etc/dev.d/ scripts - than you will
    really end up with FSMs in shell scripts. You are welcome to try. I did
    once and failed.

    P.P.S. Well, I will stop trolling. Honestly. Promise.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Tuomas Heino: "vfs hacking q: implementing "sectorfs" - hints?"

    Relevant Pages

    • Re: Developing a Device Driver
      ... > be nice to present to users as a file system - the data that is produced ... > This is why I initially thought about a RAM disk type approach, ... Can I get access to the network through a driver? ... > the right term) kernel proxy, that would allow a user mode application to ...
      (microsoft.public.development.device.drivers)
    • Re: Partially checked build vs. fully checked build
      ... applications will cause ASSERTS on the checked build that cannot be recovered from. ... For instance if you are developing something like a file system mini-filter, or an NDIS mini-port you want the checked version of the support code. ... I'm understanding your reply correctly, so long as I include the checked builds of the kernel & the HAL, then things should function fairly well for kernel mode debugging of drivers w/o introducing a whole lot of extra issues to be aware of in terms of having Windows still perform faily well & w/o introducing a lot of extra things that will interrupt that functionality. ... And if I include the checked builds of the file system components, including the driver for NTFS and the filesystem filter manager, etc..., then file system filter & minifilter debugging should be faciliated, too? ...
      (microsoft.public.win32.programmer.kernel)
    • Re: how can I identify which processes access a file?
      ... You can use API hooking and monitor for e.g. ... approcah is to develop a kernel file system driver ... going to your kernel driver either by DeviceIoControl ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: Boot-up Questions-I.
      ... kernel from a floppy, ... The boot sector is loaded to that address. ... that driver to access the root file system. ...
      (comp.os.linux.development.system)
    • PROBLEM: EHCI Driver hard-locks system when USB devices plugged. (2.4.21 & 2.6.0-test2)
      ... The kernel boot messages were copied by hand from 2.6.0-test2, with USB ... PCI: cache line size of 128 is not supported by device 0000:00:1d.7 ... [root@elbmin3 scripts]# sh ./ver_linux ...
      (Linux-Kernel)