linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Weiser <michael@weiser.dinsnail.net>
To: Greg KH <greg@kroah.com>
Cc: linux-hotplug-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE] udev 021 release
Date: Wed, 03 Mar 2004 09:56:15 +0000	[thread overview]
Message-ID: <20040303095615.GA89995@weiser.dinsnail.net> (raw)
In-Reply-To: <20040303000957.GA11755@kroah.com>

On Tue, Mar 02, 2004 at 04:09:57PM -0800, Greg KH wrote:
> Major changes from the 019 version:
> 	- new variable $local for the udev.permission file allows
> 	  permissions to be set for the currently logged in user.
Yay, just the other day I thought that might be a nice feature in
concert with RedHat's/Fedora's pam_console module. Am I right in
assuming that the current utmp based code will give the file to the user
that most recently logged into the local console? This could cause some
confusion with the pam_console-method which gives files to the user that
logged in *first* on a local console.

Call me stupid but I have two other questions that look quite simple but
I can't seem to wrap my head about:

Normally with static /dev one has a /dev/dsp device for example. As soon
as an application tries to open it the kernel would try to load a module
"sound" or "char-major-something" if sound support isn't compiled into
it. Now with udev I'll never get /dev/dsp in the first place and there's
no mechanism like devfs's file open monitoring and subsequent device
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.

Also I very much liked the automatic creation of /dev/root by devfs
because it kept the system bootable after moves around different
harddrives and partitions several times where I would normally have
forgotten to adjust fstab to the new root. I poked around sysfs and proc
a bit but can't seem to find anything that would permit me to simlute
that behaviour with udev. Does udev perhaps already support something
like this?

Thanks in advance for any advice.
-- 
bye, Micha


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&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

  parent reply	other threads:[~2004-03-03  9:56 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-03  0:09 [ANNOUNCE] udev 021 release 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 [this message]
2004-03-03 12:22   ` Ed Tomlinson
2004-03-03 15:14     ` Greg KH
2004-03-03 19:28       ` David Brownell
2004-03-03 22:53       ` Michael Weiser
2004-03-04  1:25         ` Greg KH
2004-03-04  3:58           ` Bill Nottingham
2004-03-04 18:26             ` Greg KH
2004-03-04  1:22       ` Marco d'Itri
2004-03-04  1:28         ` Greg KH
2004-03-04  9:27           ` Michael Weiser
2004-03-03 15:15   ` Greg KH
2004-03-03 23:56     ` Michael Weiser
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
     [not found] ` <4046CE91.50701@kubla.de>
2004-03-04 18:44   ` Greg KH
     [not found]     ` <40482ACC.3070504@kubla.de>
2004-03-10 22:53       ` Greg KH
     [not found] ` <1078422507.3614.20.camel@nosferatu.lan>
2004-03-04 18:46   ` Greg KH
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 22:51   ` Greg KH
2004-03-10 23:17     ` Prakash K. Cheemplavam
2004-03-11  1:21       ` Greg KH
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] <20040303153403.21649.81059.Mailman@linux.us.dell.com>
     [not found] ` <4048D503.10808@mail.ru>
2004-03-09  8:19   ` Greg KH
2004-03-09 10:16     ` rihad
2004-03-09 13:43       ` Alex Goddard
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 21:01     ` Prakash K. Cheemplavam
     [not found] <fa.fkf6pbs.vk4328@ifi.uio.no>
     [not found] ` <fa.aj3o3v7.pgqn9l@ifi.uio.no>
     [not found]   ` <404F9E5F.2010001@myrealbox.com>
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=20040303095615.GA89995@weiser.dinsnail.net \
    --to=michael@weiser.dinsnail.net \
    --cc=greg@kroah.com \
    --cc=linux-hotplug-devel@lists.sourceforge.net \
    --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;
as well as URLs for NNTP newsgroup(s).