From: Mike Snitzer <msnitzer@lnxi.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: Non-hardware devices like loop: another idea
Date: Thu, 18 Mar 2004 04:55:34 +0000 [thread overview]
Message-ID: <20040317215534.A26919@lnxi.com> (raw)
In-Reply-To: <200403122003.00557.patrakov@ums.usu.ru>
On Wed, Mar 17 2004 at 20:56,
Alexander E. Patrakov <patrakov@ums.usu.ru> wrote:
> > So wouldn't a better option be to make the various devices that don't
> > support hotplug and/or sysfs support them? Then udev just needs some new
> > rules. Infering information from the module load (via modules.alias) is
> > fragile.
>
> The loop module supports sysfs, and generated hotplug events when inserted or
> removed. The problem is that you cannot make the current hotplug scripts
> insert this module at hardware detection phase. If you know something
> different, please tell us how (based on what information) would you make
> devices such as loop, lp, ppdev (note that they properly support sysfs, but
> can't be detected as hardware) present in /dev? The only other solution
> mentioned here was to keep a big tarball of such undetectable devices and
> untar it every boot.
Ok, so at system boot umlstart walks sysfs and populates /dev accordingly;
loop devices work great. GregKH says tun/tap devices now work in 2.6.4;
so ultimately its just a matter of adding sysfs support to the various
device drivers.
But your desire for loading modules when a device node is accessed isn't
doable.
Mike
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next prev parent reply other threads:[~2004-03-18 4:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-12 15:03 Non-hardware devices like loop: another idea Alexander E. Patrakov
2004-03-17 1:47 ` Mike Snitzer
2004-03-17 4:13 ` Alexander E. Patrakov
2004-03-17 4:26 ` Mike Snitzer
2004-03-17 6:39 ` Alexander E. Patrakov
2004-03-17 17:01 ` Mike Snitzer
2004-03-18 3:56 ` Alexander E. Patrakov
2004-03-18 4:24 ` Greg KH
2004-03-18 4:55 ` Mike Snitzer [this message]
2004-03-18 9:55 ` Alexander E. Patrakov
2004-03-18 9:58 ` Alexander E. Patrakov
2004-03-18 10:23 ` Marco d'Itri
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=20040317215534.A26919@lnxi.com \
--to=msnitzer@lnxi.com \
--cc=linux-hotplug@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.