I've released the 021 version of udev. It can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-021.tar.gz
(Yes, there was no 020 release announcement, that tarball had a number
of build issues that prevented rpms from being generated, hence the need
for a 021 release. A certain new Ximian/SuSE/Novell employee owes me
some beer now that he broke the build and I had to fix it...)
rpms built against Red Hat FC2-test1 are available at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-021-1.i386.rpm
with the source rpm at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-021-1.src.rpm
udev allows users to have a dynamic /dev and provides the ability to
have persistent device names. It uses sysfs and /sbin/hotplug and runs
entirely in userspace. It requires a 2.6 kernel with CONFIG_HOTPLUG
enabled to run. Please see the udev FAQ for any questions about it:
kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ
For any udev vs devfs questions anyone might have, please see:
kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs
I think udev is pretty much mature now. The TODO list is pretty much
empty, and I've integrated in all of the assorted patches that the
different distros were using. If there's anything missing from udev, or
any patches that I've missed, please let me and the people at the
linux-hotplug-devel mailing list know about it.
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.
- new binary, udevstart, to help out people with distros that
needed the udev_start program to have a few /dev entries be
created before it could run.
- new udevinfo functionality (can handle the symlinks correctly
now.)
- number of other small fixes.
Thanks to everyone who has send me patches for this release, a full list
of everyone, and their changes is below.
udev development is done in a BitKeeper repository located at:
bk://linuxusb.bkbits.net/udev
Daily snapshots of udev from the BitKeeper tree can be found at:
http://www.codemonkey.org.uk/projects/bitkeeper/udev/
If anyone ever wants a tarball of the current bk tree, just email me.
thanks,
greg k-h
Summary of changes from v020 to v021
============================================
Kay Sievers:
o install udevinfo in /usr/bin
o blacklist pcmcia_socket
Greg Kroah-Hartman:
o fix udev.spec to find udevinfo now that it has moved to /usr/bin
o Fix another problem with Makefile installing initscript
o fix the Makefile to install the init script into the proper directory
o make spec file turn off selinux support by default
o 020 release TAG: v020
Summary of changes from v019 to v020
============================================
<christophe.varoqui:free.fr>:
o multipath update
Kay Sievers:
o man page udevstart
o cleanup udevstart
o bugfix for local user
o unlink bugfix
o TODO update
o clarify udevinfo device walk
o udevinfo symlink reverse query
o fix stroul endptr use
o add $local user spport for permissions
o udev - man page update
o udev - fix debug info for multiple rule file config
o udev - kill udevd on install
o udev - activate formt length attribute
o udev - safer sprintf() use
<md:linux.it>:
o no error on enoent
o escape dashes in man pages
o remove usage of expr in ide-devfs.sh
<rml:ximian.com>:
o automatically install correct initscript
o update documetation for $local
Andrey Borzenkov:
o Add symlink only rules support
Greg Kroah-Hartman:
o update the TODO list as we already have a devfs config file
o make start_udev use udevstart binary
o install udevstart
o Remove Debian permission files as the Debian maintainer doesn't seem to want to share :(
o update the Gentoo rules files
o Add Red Hat rules and permissions files
o add udevstart to the ignore list
o add udevstart program based on a old patch from Harald Hoyer <[email protected]>
o unlink the file before we try to create it
o Merge greg@bucket:/home/greg/src/udev into kroah.com:/home/greg/src/udev
o 019_bk mark
o 018 release TAG: v019
On Tue, Mar 02, 2004 at 04:09:57PM -0800, Greg KH wrote:
> I've released the 021 version of udev. It can be found at:
> kernel.org/pub/linux/utils/kernel/hotplug/udev-021.tar.gz
Two other things about this release that Kay just reminded me about:
- if you have been using the tarballs, please delete
/sbin/udevinfo by hand, as it is now placed in
/usr/bin/udevinfo. Users who use the rpm or some other kind
of package system will have no problems with this.
- the old style %2c format has now been removed in favor of the
%c{2} style. Any old udev.rules files will need to be
converted (you had a few releases to do this...)
And another one I just remembered:
- we now support multiple symlink rules. They aren't really
documented well, but hopefully the author of that patch will
fix this soon...
thanks,
greg k-h
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
On March 03, 2004 04:56 am, Michael Weiser wrote:
> 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.
Would it be possible to have something in the module itself? i.e. We create
a new macro to add info that a script can use. This info could live in a new file
in lib/modules or in the actual module. This could be used to create the static
setup dynamicly.
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...
Ed Tomlinson
On Wed, 03 Mar 2004 11:10:11 +0100, you wrote in linux.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?
You could do that in early user-space by reading
/proc/sys/kernel/real-root-dev and setting up /dev/root from that
information.
--
Ciao,
Pascal
On Wed, Mar 03, 2004 at 07:22:17AM -0500, Ed Tomlinson wrote:
> On March 03, 2004 04:56 am, Michael Weiser wrote:
> > 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.
>
> Would it be possible to have something in the module itself? i.e. We create
> a new macro to add info that a script can use. This info could live in a new file
> in lib/modules or in the actual module. This could be used to create the static
> setup dynamicly.
>
> 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.
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.
So no, udev is not going to handle this "issue" except in the case of
removable devices and their partitions. Which is already working in
udev today.
thanks,
greg k-h
On Wed, Mar 03, 2004 at 10:56:15AM +0100, Michael Weiser wrote:
> 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.
I don't know, care to test it out?
thanks,
greg k-h
Greg KH wrote:
> 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.
>
> 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.
Actually I think that sysadmin frameworks are the ones that'll have
the hardest time changing. It's a different way to look at system
configuration, and changing basic models incrementally may not work.
User adoption normally lags sysadmin adoption for such stuff. (Yes,
developers often wear both of those hats too.)
Luckily, all the usermode frameworks to boot and configure Linux have
had since the 2.4.0 kernel (or was that 2.4.0-test10?) to start moving
from that "historical UNIX" sysadmin model to something more modern;
Linux devices have been hotplugging for quite a while now. All that
2.6 changed was to use it more universally; and with sysfs, that also
means stuff like "udev" is now possible.
Which means that any day now, all Linux systems (and their users,
docs, and sysadmin procedures) will be done converting!
- Dave
p.s. You in the back there saying "Huh? NOT!!!". Be quiet.
p.p.s. And that "we shall coexist" chanting -- enough already!
;-)
On Wed, Mar 03, 2004 at 07:15:00AM -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.
> I don't know, care to test it out?
Aye. It's even worse. The user logged into the lowest-numbered console
will get owner of the newly created file when using $local.
So if I log into tty2 and plug in my USB stick I will be owner of
/dev/sda1. If another guy comes along, logs into tty1, unplugs my USB
stick and replugs it, he'll be owner of /dev/sda1. But if I log out now,
re-login on tty2 and replug the stick again, I won't get the owner of
/dev/sda1 but the other guy again. This will certainly break things - at
least on Fedora Core 1. Maybe it's different with other
distributions/glibc/utmp variants/versions.
Would it be an option to check for /var/run/console.lock and use the
username stored there by pam_console if present?
--
Micha
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.
Of course I sometimes need my kernel to adapt to new hardware and with
USB and other hot-pluggable things I more often need to do it during
runtime. But traditionally I've never had much of a problem just
recompiling the kernel with support for the new hardware and just that
new hardware before changing the machine. From this point of view I'd
only need loadable modules for hot-pluggables and then only load, not
unload.
But the main feature of modules for me has always been to keep my kernel
slim at runtime but also have modules for hardware I have in my machine
but almost never use. This includes floppy and CD-ROM drives and sound
hardware as well as meta-drivers such as ram disks or different
filesystems. Changing the module logic for all of them would mean a lot
of bloat elegantly avoided so far.
If udev support for yet undriven but present hardware is so hard to
implement I can certainly live with a partly static /dev. And I
certainly don't want to stir the already rather emontional devfs
advocacy. But this change in module sematics seems a bit too fundamental
to me.
> 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.)
> So no, udev is not going to handle this "issue" except in the case of
> removable devices and their partitions. Which is already working in
> udev today.
I don't really see the difference between a device I can physically
remove and one I can remove the driver for. For example: udev works
nicely for USB devices. But to do so the UHCI driver needs to be loaded.
But if I almost never use USB, the whole USB subsystem might be
something of a removeable device to me, only plugged into the kernel
when needed. Instead of limiting the approach to physical devices, can't
we expand our thinking to removable subsystems as done with modules
nicely and elegantly up to now?
--
bye, Micha
On Thu, Mar 04, 2004 at 12:56:29AM +0100, Michael Weiser wrote:
> On Wed, Mar 03, 2004 at 07:15:00AM -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.
> > I don't know, care to test it out?
> Aye. It's even worse. The user logged into the lowest-numbered console
> will get owner of the newly created file when using $local.
>
> So if I log into tty2 and plug in my USB stick I will be owner of
> /dev/sda1. If another guy comes along, logs into tty1, unplugs my USB
> stick and replugs it, he'll be owner of /dev/sda1. But if I log out now,
> re-login on tty2 and replug the stick again, I won't get the owner of
> /dev/sda1 but the other guy again. This will certainly break things - at
> least on Fedora Core 1. Maybe it's different with other
> distributions/glibc/utmp variants/versions.
Ick, well you are describing a pretty pathalogical situation. I suspect
for 99.9% of the users who would use this option, it will work just
fine, as they only have 1 user on the system at a time.
So, if you have multiple users on the physical system, then don't use
$local :)
Feel free to send a update to the documentation that illustrates this
limitation of the feature.
thanks,
greg k-h
On Mar 03, Greg KH <[email protected]> wrote:
>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.
This does not solve the problem of drivers which do not have matching
hardware, like PPP and loop device. I do not mind unconditionally loading
these modules at boot, but there has to be a way to recognize them: I do
not think it is acceptable to load *all* modules available on the system
(what is the point of having a modular kernel then?).
--
ciao, |
Marco | [4890 diVLsnWO4HAuo]
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
On Thu, Mar 04, 2004 at 02:22:33AM +0100, Marco d'Itri wrote:
> On Mar 03, Greg KH <[email protected]> wrote:
>
> >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.
> This does not solve the problem of drivers which do not have matching
> hardware, like PPP and loop device. I do not mind unconditionally loading
> these modules at boot, but there has to be a way to recognize them: I do
> not think it is acceptable to load *all* modules available on the system
> (what is the point of having a modular kernel then?).
Then have your "use the loop device" or "use the ppp device" load the
module before it is used. Or manually create the dev node and hope that
kmod and its aliases work...
thanks,
greg k-h
Greg KH ([email protected]) said:
> 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.
So, then, answer this question. In previous kernels, 2.4 and otherwise,
a driver or piece of hardware may get into a 'confused' state. You unload
the driver, reload it, it resets, everything is peachy.
How do I reinitialize a driver or hardware in your 'no-unload'
scenario?
Bill
On Tue, Mar 02, 2004 at 04:09:57PM -0800, Greg KH wrote:
> I've released the 021 version of udev. It can be found at:
> kernel.org/pub/linux/utils/kernel/hotplug/udev-021.tar.gz
Nice work, but I ran into a problem on my Debian system and i did use
the udev-019 permissions file for Debian. What's the story here anyway?
I seem to be unable to assign group "cdrom" to my ATAPI DVD/CD-RW drive.
It appears to me that the permissions syntax is missing a possibility to
overide the owner/group based upon the class of the device.
Is there a way to distinguish between CD-ROM, DVD-ROM and writers? It is
not unusual these days to have at least a DVD-ROM and CD-Writer in a
desktop system. If you look at the latest offers from Dell you will see
that they tend to include a DVD-ROM and a DVD+RW drive in at least some
configurations. So it would be nice if udev would be able to create
links like "cdwriter", "dvd" and "dvdwriter" out of the box. (And assign
the appropriate group to the device nodes...)
Regards,
Dominik
--
Confirmed bachelor:
A man who goes through life without a hitch.
On Wed, Mar 03, 2004 at 05:28:13PM -0800, Greg KH wrote:
> > This does not solve the problem of drivers which do not have matching
> > hardware, like PPP and loop device. I do not mind unconditionally loading
> > these modules at boot, but there has to be a way to recognize them: I do
> > not think it is acceptable to load *all* modules available on the system
> > (what is the point of having a modular kernel then?).
> Then have your "use the loop device" or "use the ppp device" load the
> module before it is used. Or manually create the dev node and hope that
> kmod and its aliases work...
AFAICS both require root privileges and the latter will break with
dynamic device numbers issued by the kernel. The previous model enabled
normal users to have the kernel adjust to their current requirements
dynamically without the need of being root.
--
bye, Micha
On Wed, Mar 03, 2004 at 05:25:31PM -0800, Greg KH wrote:
>
> 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.
>
while wholeheartly agreeing with you in this statement, I had to compile
modules with remove enabled for a show-stopping reason: suspend. After
resume, sound, usb mouse, pcmcia devices would not come back to life if I do
not rmmod before and reload after going to S4. I quite understand that this
is a driver problem (bug?), but for my notebook module remove is a necessary
workaround.
Romano
(tried PMSIK, SWSUSP, SWSUPS2 in 2.6.1, PMDISK works --- Vaio FX701).
--
Romano Giannetti - Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416 fax +34 915 596 569
On Wed, 2004-03-03 at 02:09, Greg KH wrote:
> I've released the 021 version of udev. It can be found at:
> kernel.org/pub/linux/utils/kernel/hotplug/udev-021.tar.gz
>
Is the issue that causes missing events with udevsend (and udev in
some cases - like alsa and it seems the -mm tree) with slower machines
known yet?
Thanks,
--
Martin Schlemmer
On Wed, Mar 03, 2004 at 10:58:56PM -0500, Bill Nottingham wrote:
> Greg KH ([email protected]) said:
> > 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.
>
> So, then, answer this question. In previous kernels, 2.4 and otherwise,
> a driver or piece of hardware may get into a 'confused' state. You unload
> the driver, reload it, it resets, everything is peachy.
>
> How do I reinitialize a driver or hardware in your 'no-unload'
> scenario?
Disconnect the hardware device. Oh, you don't have a PCI hotplug
system, well get one :)
Seriously, sure, try to unload the module. But please refer to all of
the different threads on lkml during the 2.5 development cycle about
module unloading. Also note the way that module unloading might be done
in 2.7 (by keeping the old memory around, and never freeing it...)
Also realize that it's better to fix the driver in a situation like you
mention. Unloading the driver is often times not a viable solution for
a lot of people (like if your scsi driver is also the one holding your
root disk...)
thanks,
greg k-h
On Thu, Mar 04, 2004 at 07:37:05AM +0100, Dominik Kubla wrote:
> On Tue, Mar 02, 2004 at 04:09:57PM -0800, Greg KH wrote:
> >I've released the 021 version of udev. It can be found at:
> > kernel.org/pub/linux/utils/kernel/hotplug/udev-021.tar.gz
>
> Nice work, but I ran into a problem on my Debian system and i did use
> the udev-019 permissions file for Debian. What's the story here anyway?
Debian has a "official" package. I recommend you use that if you have a
Debian system.
> I seem to be unable to assign group "cdrom" to my ATAPI DVD/CD-RW drive.
> It appears to me that the permissions syntax is missing a possibility to
> overide the owner/group based upon the class of the device.
Permissions are based on the name of the device.
> Is there a way to distinguish between CD-ROM, DVD-ROM and writers? It is
> not unusual these days to have at least a DVD-ROM and CD-Writer in a
> desktop system. If you look at the latest offers from Dell you will see
> that they tend to include a DVD-ROM and a DVD+RW drive in at least some
> configurations. So it would be nice if udev would be able to create
> links like "cdwriter", "dvd" and "dvdwriter" out of the box. (And assign
> the appropriate group to the device nodes...)
You can do that, just name them differently based on the type of device.
Also, try providing a symlink to "cdrom" to not break what users are
expecting.
thanks,
greg k-h
On Thu, Mar 04, 2004 at 07:48:27PM +0200, Martin Schlemmer wrote:
> On Wed, 2004-03-03 at 02:09, Greg KH wrote:
> > I've released the 021 version of udev. It can be found at:
> > kernel.org/pub/linux/utils/kernel/hotplug/udev-021.tar.gz
> >
>
> Is the issue that causes missing events with udevsend (and udev in
> some cases - like alsa and it seems the -mm tree) with slower machines
> known yet?
No, this is not really known. I've heard rumors of it, but been unable
to duplicate it here. Some solid error reports would be greatly
appreciated...
thanks,
greg k-h
On Thu, 2004-03-04 at 20:46, Greg KH wrote:
> On Thu, Mar 04, 2004 at 07:48:27PM +0200, Martin Schlemmer wrote:
> > On Wed, 2004-03-03 at 02:09, Greg KH wrote:
> > > I've released the 021 version of udev. It can be found at:
> > > kernel.org/pub/linux/utils/kernel/hotplug/udev-021.tar.gz
> > >
> >
> > Is the issue that causes missing events with udevsend (and udev in
> > some cases - like alsa and it seems the -mm tree) with slower machines
> > known yet?
>
> No, this is not really known. I've heard rumors of it, but been unable
> to duplicate it here. Some solid error reports would be greatly
> appreciated...
>
Besides reports from others, my work box also shows this - they just do
not endorse (and don't want to find out if they will mind) me doing
work in this field. I will however try to track or get some type of
test case.
--
Martin Schlemmer
Greg KH wrote:
> On Thu, Mar 04, 2004 at 07:37:05AM +0100, Dominik Kubla wrote:
>
>>On Tue, Mar 02, 2004 at 04:09:57PM -0800, Greg KH wrote:
>>
>>>I've released the 021 version of udev. It can be found at:
>>> kernel.org/pub/linux/utils/kernel/hotplug/udev-021.tar.gz
>>
>>Nice work, but I ran into a problem on my Debian system and i did use
>>the udev-019 permissions file for Debian. What's the story here anyway?
>
>
> Debian has a "official" package. I recommend you use that if you have a
> Debian system.
Hmm. Yes, i just tried it, but i am not impressed. Somebody tried very
hard to make the resulting /dev look like devfs instead of following
devices.txt... Especially unconditionally using tmpfs for /dev is a
bad idea if the user wants/needs to use ACLs.
So i'll continue to work from your sources.
>
>>I seem to be unable to assign group "cdrom" to my ATAPI DVD/CD-RW drive.
>>It appears to me that the permissions syntax is missing a possibility to
>>overide the owner/group based upon the class of the device.
>
>
> Permissions are based on the name of the device.
>
Oh, i realized that. But my point is: shouldn't they be based on the
CLASS of the device rather than the name? After all the names are
changeable, but the class is not...
I checked the hotplug-devel archives and saw that somebody has already
posted a patch doing that. So i guess the question boils down to:
Will you accept it or not?
>>Is there a way to distinguish between CD-ROM, DVD-ROM and writers? It is
>>not unusual these days to have at least a DVD-ROM and CD-Writer in a
>>desktop system. If you look at the latest offers from Dell you will see
>>that they tend to include a DVD-ROM and a DVD+RW drive in at least some
>>configurations. So it would be nice if udev would be able to create
>>links like "cdwriter", "dvd" and "dvdwriter" out of the box. (And assign
>>the appropriate group to the device nodes...)
>
>
> You can do that, just name them differently based on the type of device.
> Also, try providing a symlink to "cdrom" to not break what users are
> expecting.
Would you care to explain how to do it?
TIA,
Dominik
On Fri, Mar 05, 2004 at 11:29:07PM +0400, rihad wrote:
> Date: Wed, 3 Mar 2004 07:14:33 -0800
> From: Greg KH <[email protected]>
>
> >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.
>
> Does this mean that I will have modules for all my hardware hanging
> around even if I'm not, say, using cdrom at the moment?
Yup, why not?
> And does it mean that if I rmmod -a the unused cdrom module and later
> try to mount /cdrom, the correct module won't be magically insmod'ed?
If you don't have the /dev entry there, how would anything know to load
the module?
> I like the idea of lazy module loading, and it seems that your model
> doesn't fit in nicely, I could be wrong.
How about "loading the modules for the hardware present"? What's wrong
with that?
thanks,
greg k-h
Greg KH wrote:
> On Fri, Mar 05, 2004 at 11:29:07PM +0400, rihad wrote:
>
>>Date: Wed, 3 Mar 2004 07:14:33 -0800
>>From: Greg KH <[email protected]>
>>
>>>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.
>>
>>Does this mean that I will have modules for all my hardware hanging
>>around even if I'm not, say, using cdrom at the moment?
>
>
> Yup, why not?
>
I suspect there's nothing wrong with that under many common scenarios
(apart from the one thing I seem to dislike so much that if a cdrom
isn't being used, no driver for it should be loaded). But it does impose
certain amount of strict policy that Unix (and Linux more so) has long
been doing a great job of avoiding.
>
>>And does it mean that if I rmmod -a the unused cdrom module and later
>>try to mount /cdrom, the correct module won't be magically insmod'ed?
>
>
> If you don't have the /dev entry there, how would anything know to load
> the module?
>
Does the devfs/udev /dev entry get removed when doing rmmod? I though
not. But since the module isn't there anymore, doing mount /dev/cdrom
/cdrom would give "No such device". Not a problem per se, but then
probably rmmod -a isn't as a wise thing to do with udev as it is with
devfs. Bad.
On Tue, 9 Mar 2004, rihad wrote:
[Snip]
> Does the devfs/udev /dev entry get removed when doing rmmod? I though
> not. But since the module isn't there anymore, doing mount /dev/cdrom
> /cdrom would give "No such device". Not a problem per se, but then
> probably rmmod -a isn't as a wise thing to do with udev as it is with
> devfs. Bad.
See past linux-kernel threads on how problematic module unloading is (and
how insanely hard it'd be to fix those problems). You really shouldn't be
using rmmod unless you're a developer as it is.
--
Alex Goddard
agoddard at purdue dot edu
Hi,
I have a problem with udev and my ZIP drive (using latest mm based kernel):
When I insert a zip the /dev for the partition doesn't get created (ie
hdd4, fdisk shows it though).
What is the problem?
1) ATAPI Floppy lacks sysfs support?
2) I need to write some sort of rule?
3) Problem of udev?
4) something else?
Thanx,
Prakash
Prakash K. Cheemplavam wrote:
> When I insert a zip the /dev for the partition doesn't get created (ie
> hdd4, fdisk shows it though).
My Zips always show up as /dev/sda4 (scsi disks).
walt wrote:
> Prakash K. Cheemplavam wrote:
>
>> When I insert a zip the /dev for the partition doesn't get created (ie
>> hdd4, fdisk shows it though).
>
>
> My Zips always show up as /dev/sda4 (scsi disks).
Do you have SCSI support compiled in? For me it doesn't (I have no SCSI
support in, as well.) Are you using a USB ZIP? I have a ATAPI ZIP, so it
makes no sense appearing as a SCSI device.
Prakash
On Tue, Mar 09, 2004 at 02:16:06PM +0400, rihad wrote:
>
> Does the devfs/udev /dev entry get removed when doing rmmod? I though
> not.
Yes it does. If the sysfs entry goes away.
> But since the module isn't there anymore, doing mount /dev/cdrom
> /cdrom would give "No such device". Not a problem per se, but then
> probably rmmod -a isn't as a wise thing to do with udev as it is with
> devfs. Bad.
rmmod -a has not been a wise thing to do since 2.2 came out. It can
easily take down a working box...
thanks,
greg k-h
On Wed, Mar 10, 2004 at 01:56:37PM +0100, Prakash K. Cheemplavam wrote:
> Hi,
>
> I have a problem with udev and my ZIP drive (using latest mm based kernel):
>
> When I insert a zip the /dev for the partition doesn't get created (ie
> hdd4, fdisk shows it though).
>
> What is the problem?
>
> 1) ATAPI Floppy lacks sysfs support?
> 2) I need to write some sort of rule?
> 3) Problem of udev?
> 4) something else?
Do you have udev creating all partitions for your hdd device? That
sounds like the option that you need to use.
thanks,
greg k-h
On Fri, Mar 05, 2004 at 08:22:52AM +0100, Dominik Kubla wrote:
> >Permissions are based on the name of the device.
> >
>
> Oh, i realized that. But my point is: shouldn't they be based on the
> CLASS of the device rather than the name? After all the names are
> changeable, but the class is not...
>
> I checked the hotplug-devel archives and saw that somebody has already
> posted a patch doing that. So i guess the question boils down to:
> Will you accept it or not?
Ok, I'm convinced now. I just took a patch that does this.
> >>Is there a way to distinguish between CD-ROM, DVD-ROM and writers? It is
> >>not unusual these days to have at least a DVD-ROM and CD-Writer in a
> >>desktop system. If you look at the latest offers from Dell you will see
> >>that they tend to include a DVD-ROM and a DVD+RW drive in at least some
> >>configurations. So it would be nice if udev would be able to create
> >>links like "cdwriter", "dvd" and "dvdwriter" out of the box. (And assign
> >>the appropriate group to the device nodes...)
> >
> >
> >You can do that, just name them differently based on the type of device.
> >Also, try providing a symlink to "cdrom" to not break what users are
> >expecting.
>
> Would you care to explain how to do it?
Is there some way that you can see in sysfs or in /proc that you can use
to detect these devices differently?
thanks,
greg k-h
Greg KH wrote:
> On Wed, Mar 10, 2004 at 01:56:37PM +0100, Prakash K. Cheemplavam wrote:
>>I have a problem with udev and my ZIP drive (using latest mm based kernel):
>>
>>When I insert a zip the /dev for the partition doesn't get created (ie
>>hdd4, fdisk shows it though).
>
> Do you have udev creating all partitions for your hdd device? That
> sounds like the option that you need to use.
>
Nope, I don't have any special udev treatment for that device. Could you
give me a clearer hint (docs?)? :-) I guess something about udev.rules?
Prakash
Prakash K. Cheemplavam wrote:
> walt wrote:
>
>> Prakash K. Cheemplavam wrote:
>>
>>> When I insert a zip the /dev for the partition doesn't get created
>>> (ie hdd4, fdisk shows it though).
>>
>>
>>
>> My Zips always show up as /dev/sda4 (scsi disks).
>
>
> Do you have SCSI support compiled in? For me it doesn't (I have no SCSI
> support in, as well.) Are you using a USB ZIP? I have a ATAPI ZIP, so it
> makes no sense appearing as a SCSI device.
Yes, I have SCSI support compiled into the kernel, and SCSI-disk as well.
If you have SCSI/SCSI-disk support compiled as modules they should be loaded
automatically.
As far as I know all Zip drives are SCSI devices disguised as parallel/USB/
IDE devices, but all required SCSI-disk support because that is what they
really are underneath the disguise.
Try it and see what happens.
walt wrote:
> Prakash K. Cheemplavam wrote:
>
>> walt wrote:
>>
>>> Prakash K. Cheemplavam wrote:
>>>
>>>> When I insert a zip the /dev for the partition doesn't get created
>>>> (ie hdd4, fdisk shows it though).
>>>
>>>
>>>
>>>
>>> My Zips always show up as /dev/sda4 (scsi disks).
>>
>>
>>
>> Do you have SCSI support compiled in? For me it doesn't (I have no
>> SCSI support in, as well.) Are you using a USB ZIP? I have a ATAPI
>> ZIP, so it makes no sense appearing as a SCSI device.
>
>
> Yes, I have SCSI support compiled into the kernel, and SCSI-disk as well.
> If you have SCSI/SCSI-disk support compiled as modules they should be
> loaded
> automatically.
>
> As far as I know all Zip drives are SCSI devices disguised as parallel/USB/
> IDE devices, but all required SCSI-disk support because that is what they
> really are underneath the disguise.
>
> Try it and see what happens.
Nope, I don't think so, because before udev with the evil devfs
/dev/hdd4 appeared...
So, unless you have a ATAPI ZIp on your own, I won't bother trying SCSI.
bye,
Prakash
On Thu, Mar 11, 2004 at 12:17:12AM +0100, Prakash K. Cheemplavam wrote:
> Greg KH wrote:
> >On Wed, Mar 10, 2004 at 01:56:37PM +0100, Prakash K. Cheemplavam wrote:
> >>I have a problem with udev and my ZIP drive (using latest mm based
> >>kernel):
> >>
> >>When I insert a zip the /dev for the partition doesn't get created (ie
> >>hdd4, fdisk shows it though).
> >
> >Do you have udev creating all partitions for your hdd device? That
> >sounds like the option that you need to use.
> >
>
> Nope, I don't have any special udev treatment for that device. Could you
> give me a clearer hint (docs?)? :-) I guess something about udev.rules?
See the manpage for udev and look at the NAME{all_partitions} section.
Good luck,
greg k-h
Greg KH wrote:
> On Thu, Mar 11, 2004 at 12:17:12AM +0100, Prakash K. Cheemplavam wrote:
>
>>Greg KH wrote:
>>
>>>On Wed, Mar 10, 2004 at 01:56:37PM +0100, Prakash K. Cheemplavam wrote:
>>>
>>>>I have a problem with udev and my ZIP drive (using latest mm based
>>>>kernel):
>>>>
>>>>When I insert a zip the /dev for the partition doesn't get created (ie
>>>>hdd4, fdisk shows it though).
>
> See the manpage for udev and look at the NAME{all_partitions} section.
>
Well, I tried several variatons of following rule:
SYSFS{dev}="22:64", KERNEL="hdd", NAME{all_partitions}="hdd%n"
But no partitions popped up. I searched a bit in lkml and some time ago,
there was a thread about a jaz drive with the same problem. It rather
seems udev doesn't see the partitions appearing or I do something wrong.
For the time being I just put this into my local.start:
mknod -m 660 /dev/hdd4 b 22 68
chown root:disk hdd4
If you are sure udev should hanlde it, it would be nice if you kick me a
bit further into the right direction...
Prakash
PS:udevinfo -a -p /sys/block/hdd/
udevinfo starts with the device the node belongs to and then walks up the
device chain to print for every device found all possibly useful attributes
in the udev key format.
Only attributes within one device section may be used in a rule to match the
device for which the node will be created.
device '/sys/block/hdd' has major:minor 22:64
looking at class device '/sys/block/hdd':
SYSFS{dev}="22:64"
SYSFS{range}="64"
SYSFS{size}="196608"
SYSFS{stat}=" 35 0 42 747 0 0
0 0 0 747 747"
follow the class device's "device"
looking at the device chain at
'/sys/devices/pci0000:00/0000:00:09.0/ide1/1.1':
BUS="ide"
ID="1.1"
SYSFS{detach_state}="0"
looking at the device chain at
'/sys/devices/pci0000:00/0000:00:09.0/ide1':
BUS=""
ID="ide1"
SYSFS{detach_state}="0"
looking at the device chain at '/sys/devices/pci0000:00/0000:00:09.0':
BUS="pci"
ID="0000:00:09.0"
SYSFS{detach_state}="0"
SYSFS{vendor}="0x10de"
SYSFS{device}="0x0065"
SYSFS{subsystem_vendor}="0x147b"
SYSFS{subsystem_device}="0x1c00"
SYSFS{class}="0x01018a"
SYSFS{irq}="0"
looking at the device chain at '/sys/devices/pci0000:00':
BUS=""
ID="pci0000:00"
SYSFS{detach_state}="0"