From: Greg KH <greg@kroah.com>
To: Michael Weiser <michael@weiser.dinsnail.net>
Cc: Ed Tomlinson <edt@aei.ca>,
linux-hotplug-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE] udev 021 release
Date: Thu, 04 Mar 2004 01:25:31 +0000 [thread overview]
Message-ID: <20040304012531.GC2207@kroah.com> (raw)
In-Reply-To: <20040303225305.GB30608@weiser.dinsnail.net>
On Wed, Mar 03, 2004 at 11:53:05PM +0100, Michael Weiser wrote:
> On Wed, Mar 03, 2004 at 07:14:33AM -0800, Greg KH wrote:
> > > > file creation. So my idea is to initialise /dev with some static files,
> > > > for hardware I know is there but hasn't had a driver loaded yet. My
> > > > question is: Is there a nicer and more elegant way than just unpacking a
> > > > tarball into /dev before starting udevd? A tarball would also break a
> > > > (theoretical) use of dynamic major/minor numbers by the kernel.
> > > This item keeps coming up as the one feature that devfs has and udev
> > > does not. It keeps getting dismissed. Users seem to actually want it...
> > Users need to learn that the kernel is changing models from one which
> > automatically loaded modules when userspace tried to access the device,
> > to one where the proper modules are loaded when the hardware is found.
> Is this a general roadmap decision already made by all the developers or
> a proposal? If the latter I'd very much like to advocate for the old
> model.
Sorry, but you're a bit late. We've been moving this way since before
2.4.0.
The fact that module unload even works today is a blessing due to all of
the well-documented issues involved. I doubt any distro will enable
module unloading because of it.
> If udev support for yet undriven but present hardware is so hard to
> implement I can certainly live with a partly static /dev.
That's fine, and the proper response, as it's impossible to sove with
udev.
> > Note that this is a much more sane model due to removable devices, and
> > instances of multiple types of the same kind of devices in the same
> > system.
> I have to admit - I haven't become aware of the issue until recently
> when trying to switch from 2.4 to 2.6 and seeing that devfs is
> depreceated now. Where do the problems lie with the current model? (I
> don't mean devfs vs. udev now - I read the README.)
{sigh} Please read the archives. This comes up about every other week
these days it seems...
thanks,
greg k-h
-------------------------------------------------------
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
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <greg@kroah.com>
To: Michael Weiser <michael@weiser.dinsnail.net>
Cc: Ed Tomlinson <edt@aei.ca>,
linux-hotplug-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE] udev 021 release
Date: Wed, 3 Mar 2004 17:25:31 -0800 [thread overview]
Message-ID: <20040304012531.GC2207@kroah.com> (raw)
In-Reply-To: <20040303225305.GB30608@weiser.dinsnail.net>
On Wed, Mar 03, 2004 at 11:53:05PM +0100, Michael Weiser wrote:
> On Wed, Mar 03, 2004 at 07:14:33AM -0800, Greg KH wrote:
> > > > file creation. So my idea is to initialise /dev with some static files,
> > > > for hardware I know is there but hasn't had a driver loaded yet. My
> > > > question is: Is there a nicer and more elegant way than just unpacking a
> > > > tarball into /dev before starting udevd? A tarball would also break a
> > > > (theoretical) use of dynamic major/minor numbers by the kernel.
> > > This item keeps coming up as the one feature that devfs has and udev
> > > does not. It keeps getting dismissed. Users seem to actually want it...
> > Users need to learn that the kernel is changing models from one which
> > automatically loaded modules when userspace tried to access the device,
> > to one where the proper modules are loaded when the hardware is found.
> Is this a general roadmap decision already made by all the developers or
> a proposal? If the latter I'd very much like to advocate for the old
> model.
Sorry, but you're a bit late. We've been moving this way since before
2.4.0.
The fact that module unload even works today is a blessing due to all of
the well-documented issues involved. I doubt any distro will enable
module unloading because of it.
> If udev support for yet undriven but present hardware is so hard to
> implement I can certainly live with a partly static /dev.
That's fine, and the proper response, as it's impossible to sove with
udev.
> > Note that this is a much more sane model due to removable devices, and
> > instances of multiple types of the same kind of devices in the same
> > system.
> I have to admit - I haven't become aware of the issue until recently
> when trying to switch from 2.4 to 2.6 and seeing that devfs is
> depreceated now. Where do the problems lie with the current model? (I
> don't mean devfs vs. udev now - I read the README.)
{sigh} Please read the archives. This comes up about every other week
these days it seems...
thanks,
greg k-h
next prev parent reply other threads:[~2004-03-04 1:25 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-03 0:09 [ANNOUNCE] udev 021 release Greg KH
2004-03-03 0:09 ` Greg KH
2004-03-03 0:25 ` Greg KH
2004-03-03 0:25 ` Greg KH
2004-03-03 1:16 ` Marco d'Itri
2004-03-03 3:09 ` Greg KH
2004-03-03 9:56 ` Michael Weiser
2004-03-03 9:56 ` Michael Weiser
2004-03-03 12:22 ` Ed Tomlinson
2004-03-03 12:22 ` Ed Tomlinson
2004-03-03 15:14 ` Greg KH
2004-03-03 15:14 ` Greg KH
2004-03-03 19:28 ` David Brownell
2004-03-03 19:28 ` David Brownell
2004-03-03 22:53 ` Michael Weiser
2004-03-03 22:53 ` Michael Weiser
2004-03-04 1:25 ` Greg KH [this message]
2004-03-04 1:25 ` Greg KH
2004-03-04 3:58 ` Bill Nottingham
2004-03-04 3:58 ` Bill Nottingham
2004-03-04 18:26 ` Greg KH
2004-03-04 18:26 ` Greg KH
2004-03-04 11:30 ` Romano Giannetti
2004-03-04 1:22 ` Marco d'Itri
2004-03-04 1:22 ` Marco d'Itri
2004-03-04 1:28 ` Greg KH
2004-03-04 1:28 ` Greg KH
2004-03-04 9:27 ` Michael Weiser
2004-03-04 9:27 ` Michael Weiser
2004-03-03 15:15 ` Greg KH
2004-03-03 15:15 ` Greg KH
2004-03-03 23:56 ` Michael Weiser
2004-03-03 23:56 ` Michael Weiser
2004-03-04 1:19 ` Greg KH
2004-03-04 1:19 ` Greg KH
2004-03-03 10:19 ` Marco d'Itri
2004-03-03 10:52 ` Alexander E. Patrakov
2004-03-03 11:02 ` Marco d'Itri
2004-03-03 15:49 ` Alexander E. Patrakov
2004-03-04 1:18 ` Marco d'Itri
2004-03-04 6:37 ` Dominik Kubla
2004-03-04 18:44 ` Greg KH
2004-03-04 18:44 ` Greg KH
2004-03-05 7:22 ` Dominik Kubla
2004-03-10 22:53 ` Greg KH
2004-03-10 22:53 ` Greg KH
2004-03-04 17:48 ` Martin Schlemmer
2004-03-04 18:46 ` Greg KH
2004-03-04 18:46 ` Greg KH
2004-03-04 18:56 ` Martin Schlemmer
2004-03-09 11:51 ` "Andrey Borzenkov"
2004-03-10 2:34 ` Oliver Neukum
2004-03-10 12:29 ` "Andrey Borzenkov"
2004-03-10 12:56 ` Prakash K. Cheemplavam
2004-03-10 12:56 ` Prakash K. Cheemplavam
2004-03-10 22:51 ` Greg KH
2004-03-10 22:51 ` Greg KH
2004-03-10 23:17 ` Prakash K. Cheemplavam
2004-03-10 23:17 ` Prakash K. Cheemplavam
2004-03-11 1:21 ` Greg KH
2004-03-11 1:21 ` Greg KH
2004-03-13 9:34 ` Prakash K. Cheemplavam
2004-03-13 9:34 ` Prakash K. Cheemplavam
2004-03-11 3:30 ` Oliver Neukum
2004-03-11 9:22 ` "Andrey Borzenkov"
2004-03-12 23:39 ` Greg KH
[not found] <1vshj-2ou-9@gated-at.bofh.it>
[not found] ` <1vBuj-3YL-17@gated-at.bofh.it>
2004-03-03 13:51 ` Pascal Schmidt
[not found] <20040303153403.21649.81059.Mailman@linux.us.dell.com>
[not found] ` <4048D503.10808@mail.ru>
2004-03-09 8:19 ` Greg KH
2004-03-09 8:19 ` Greg KH
2004-03-09 10:16 ` rihad
2004-03-09 10:16 ` rihad
2004-03-09 13:43 ` Alex Goddard
2004-03-09 13:43 ` Alex Goddard
2004-03-10 22:52 ` Greg KH
2004-03-10 22:52 ` Greg KH
[not found] <fa.dbn18ei.1k46o3i@ifi.uio.no>
[not found] ` <fa.afjk56q.t0ulic@ifi.uio.no>
2004-03-10 13:02 ` walt
2004-03-10 13:02 ` walt
2004-03-10 21:01 ` Prakash K. Cheemplavam
2004-03-10 21:01 ` Prakash K. Cheemplavam
[not found] <fa.fkf6pbs.vk4328@ifi.uio.no>
[not found] ` <fa.aj3o3v7.pgqn9l@ifi.uio.no>
2004-03-10 23:01 ` walt
2004-03-11 0:11 ` Prakash K. Cheemplavam
2004-03-11 0:11 ` Prakash K. Cheemplavam
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=20040304012531.GC2207@kroah.com \
--to=greg@kroah.com \
--cc=edt@aei.ca \
--cc=linux-hotplug-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=michael@weiser.dinsnail.net \
/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.