udev support

[Nick Hudson]

I did some testing this afternoon and everything seems to be working as
far as udev goes.  Looks like all of my devices are created under /dev
correctly except for permissions.  Now I found this kind of strange
becuase devices like /dev/null and /dev/dsp are not accessible by a user
account.  Here is what the perms look like for those two:

bash-3.00# ls -la dsp
crwx------  1 root users 14, 3 Aug  7 12:29 dsp

bash-3.00# ls -la null
crwx------  1 root users 1, 3 Aug  7 07:29 null

Now what is confusing me is that if a user account is part of the
"users" group then I should be able to access it fine.  But in this case
its not working.  I went and tried changing the perms to be diffrent in
my /etc/udev/udev.permissions file and rebooted, but as you can see the
devices did not change permissions.  

Overall things went pretty well.  I had to recompile my NVIDIA kernel
module with the new sysfs patch before it would work and I had to make a
change in my xorg.conf file for my mouse to read from a diffrent device.
Other than that and the perm problem all is well.  Once I can figure out
the perm problem I will start working on the dbus and hal modules then
things should get intresting.

Nick


On Sat, 2004-08-07 at 18:37 +0200, nestu wrote:
> Hi again,
> New release. Thinking about backwards compatibility, it 
> supports defaults. If no dev=[udev|devfs|static] on cmdline, 
> it works with these defaults:
> 
> kernel 2.4.X :
> 	if you tried to boot udev, you are a blueyes: Warning msg. 
> Falls through to the next 2 options.	
> 	if you have devfsd, it will try to boot it. If not, you'll 
> get a msg and it will fall through.
> 	if you don't have devfs, it supposes you have a static 
> /dev. Will try to boot from there.
> 
> kernels 2.6.X :
> 	if you have udev installed, it will try to boot from it. If 
> not, it will fall through.
> 	If you have devfs installed, it will try to boot from it. 
> If not, it will fall through.
> 	if you have none of the above, it will think you have a 
> static /dev.
> 
> This default behaviour can be overrided from cmdline very 
> easily:
> lilo: add append="dev=$YOURCHOICE"
> grub: on 'kernel' line, after the kernel's image placement 
> add "dev=$YOURCHOICE".
> 
> I could swap devfs and udev for 2.6 kernel, since devfs is 
> currently mostly used, and later, swap them back when udev 
> is more broadly used. But, I must say, I am against this. I 
> prefer the 2.6 lusers getting used that they'll use udev in 
> the future. IAC, if they don't want udev, just don't install 
> it, and it will boot from devfs anyway.
> 
> This script has been tested on 2.6's kernels (udev on 'me 
> ol'daddy's boxen', and devfs on a 2.6 devfs install inside 
> qemu from 2.6 iso), and on a 2.4 devfs (Terry's 1.4.0 iso) 
> qemu install. All booted fine, AFAICS. You can always say I 
> am wrong! (I'm sorta expecting it, really...) I must admit 
> that at least the msgs and the tabbing needs some polishing, 
> but I think this is a good step forward.
> 
> Okay, so ppl aren't very happy playing with their boots. Do 
> like me and just test it in qemu, for example ;) Hell, if 
> you test you own box, just backup your current 
> /etc/init.d/mount, change for my script, and if you have 
> anyproblems, just boot the iso and put the old one back (I 
> did it quite a few times debugging on my dad's box! ;) Harmless.
> 
> Thanks,
> Jaime ;)))
> 
> P.S. You are better off reading the whole lot, since it is 
> quite changed, tabbing of the script included. 	
> _______________________________________________
> Lunar-dev mailing list
> Lunar-dev at lunar-linux.org
> http://lunar-linux.org/mailman/listinfo/lunar-dev