欲启用udev的同志见下文
Computer Help for the New and Veteran User for LinuxUDEV Primer
Udev Primer for 2.6 kernel.
Lot of exciting things have been happening with UDEV as of late. Due to more advancements it is possible to run a pure udev system now. Some devices still haven't been ported to sysfs yet, so you have to do a work-around with them. Otherwise you get two choices now: Run a pure udev system and add the work-arounds OR use the default Gentoo setup that uses a devices.tar.bz2 file to populate /dev. More detail on these options as we get into the setup. The most recent information is that there are still about 162 more kernel devices that still need to be ported to sysfs. So some of you will still have to use work-arounds on them. My scanner just recently started working with udev (see's it as a usbcam, but works). Now everything so far works on mine.
If you already have UDEV installed and working you might want to read DSD's Guide on Writing UDev Rules. In the links at the bottom.
Answer: Little preliminary first. What is going on in the 2.6 kernel with Devfs? Straight from the horse mouth:
Note that devfs has been obsoleted by udev,
http://www.kernel.org/pub/linux/utils/kernel/hotplug/
It has been stripped down to a bare minimum and is only provided for
legacy installations that use its naming scheme which is
unfortunately different from the names normal Linux installations
use.
RECENT CHANGES to Primer:
1) Added info: udev version 021 and up have a new binary called udevstart you may need to run for alsa/nvidia devices until those packages fixed.
2) Added info: Appears that as of kernel 2.6.4 that the option in .config for 'CONFIG_DEVPTS_FS' is no longer available, but enabled by default in the kernel and you cannot change it. Don't worry about it any longer.
What is UDEV?
In a nutshell UDEV is an replacement of DEVFS in user-space using sysfs and /sbin/hotplug. It will create and destroy /dev entries based on the current system configuration. It does this by watching the /sbin/hotplug events on the system, and reading information about these events from sysfs.
Udev works entirely in user-space, using /sbin/hotplug calls that the kernel makes whenever a device is added or removed from the kernel. All naming policy, and permission control is done in user-space.
Some links to read for more information. (Will add more later, just throwing this together right now.)
http://ftp.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ
Well your first question is probably: How do I get started with udev?
It isn't that hard at all. Unless you have never compiled a kernel, but that is something I will leave for you since it really isn't in the scope of this tutorial.
Steps to Setting Up UDEV.
1. Like mentioned above you need to install and setup the 2.6 Kernel. Your best bet for kernels to use right now are: >mm-sources-2.6.1-mm3 (right now I am using: 2.6.3-rc1-mm1) or >gentoo-dev-sources-2.6.1 or >development-sources-2.6.2. Watch the Greater-Than sign and get a kernel newer than. Udev will work with some of the lesser kernels, but improvements have been made, so it will improve your success with a newer kernel. The important part of the configuration is shown below. Also note: You can still compile in DEVFS if you want and choose which to use at boot, so don't feel you cannot compile devfs in to use udev. See the editing lilo.conf or grub section for more details. NOTE: DO NOT Enable Devfs to Automatically load at Boot!! Haven't seen this before, but at least as of baselayout-1.8.6.13-r1 it will ignore your 'nomount' option in the bootloader. It will try to load devfs no matter what setting you have in the new /etc/conf.d/rc file. Your system will not boot and will fail at 'checking root filesystem'. The filesystem isn't corrupt though. You will need to chroot from somewhere else and take OUT the option to Automatically Start Devfs at boot and recompile the kernel. You might even have to do it with 'make mrproper'. I found out the hard way.
There are some options in the config that do not show up during menuconfig that will if you look at the .config itself. So if you want to check the file itself, this is what it should look like. Also in some kernels CONFIG_HOTPLUG might appear somewhere else, like in General Setup. You could grep what you are looking for in the .config file and then go back to menuconfig to set it. (hint)
mm-sources-2.6.3-rc1-mm1 example:
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_HOTPLUG=y
#
# File systems
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set <--- Can say 'Y' if want, will have to add devfs=nomount to boot-loader to boot with udev.
CONFIG_DEVPTS_FS=y Do Not set Devfs to load Automatically at Boot!!!
# CONFIG_DEVPTS_FS_XATTR is not set Also: as of 2.6.4 kernel, DEVPTS_FS option is not avail. Enabled in kernel.
CONFIG_TMPFS=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
You can still compile DEVFS (CONFIG_DEVFS_FS) in the kernel if you want, but see warning above. If you do, there are some boot options for lilo or grub that will mention later, where you can switch between the two. Remember though that devfs has been stripped down. Also make note that if you make changes in devfs and reboot the changes won't be saved for udev. The only way to save device state with udev is if using the /lib/udev-state/devices.tar.bz2 in the default Gentoo Udev install. If your running a pure udev system (ie. Not using devices.tar.bz2), then no changes will be saved, it is dynamic. You could try adding to the /etc/udev/udev.rules.
2. Next: emerge udev . Get at least version 017, earlier versions still work, but you might run into more problems. So best to get the latest. Udev also depends on sysfsutils and hotplug. So it will emerge them also if you don't have them. Right now sysfsutils is version sysfsutils-0.4.0 and hasn't changed in awhile.
3. Add Hotplug to your boot run-level: rc-update add hotplug boot. Note: You might want to check that you don't have hotplug also set for default run-level. You can check with: rc-update -s Which will display something like this (shortened):
bash-2.05b# rc-update -s
alsasound | boot
hdparm | default
hostname | boot
hotplug | boot
If you do then: rc-update del hotplug default to remove it.
4. Looks like Gentoo is now creating the /sys folder in root for you to mount sysfs on. At least on new installs, might as well if changing to udev also. Best that you still check for the time being and if not being created in / , then create it manually. With: mkdir /sys
5. Gentoo is now handling the mounting of devpts and sys now. So you don't have to add an either entry to /etc/fstab. The /sbin/rc script is handling it now. You can check with df -a. I haven't had any issues with them in fstab, but if you do, it is safe to remove those entries now. If you are having a problem with devpts or sys not mounting and not being able to open a console session, you should probably look for other issues causing this.
Note that devfs no longer manages /dev/pts! If you are using UNIX98
ptys, you will also need to enable (and mount) the /dev/pts
filesystem (CONFIG_DEVPTS_FS).
Now at this point you might think you actually have udev, sysfs and hotplug installed and ready to go. Sorry, but NO. Until sysfs is mounted, /dev mounted in ramfs and hotplug started you aren't really doing anything. You will see changes in /sys if remove or add devices, but the system isn't is not doing anything with this information.
6. The next item you need is the new baselayout. It contains the necessary init scripts to start this up. You need to: emerge baselayout . The latest version is baselayout-1.8.6.13 . Since udev is still a work in progress get at least that version and newer if possible. Above version does have the necessary init scripts,...
One file you might notice if look is in /lib/udev-state called devices.tar.bz2 . This is where the current state of /dev will be saved from ramfs when you shut down and where it will get it when you boot.
Saving the state of /dev kind of goes grain of what UDEV is all about doesn't it? Udev is suppose to be a dynamic filesystem that creates only the devices on your system and only when needed, for example: your scanner isn't plugged in, you don't need a device for it, so it is not created. You plug it in, then udev creates the device. If the state of /dev is saved, then it would be there next time, even if not plugged in. The reason for doing so was because at first only the basic devices needed were created by Udev. Devices like block (harddrives), tty,... UDEV has come a long way now and has most of the functionality you need now. So it is possible to run a Pure Udev system now. There are a few problems, but there are work-arounds for them.
Pretty soon Gentoo will probably remove the devices.tar.bz2 file, when udev gets further along. It looks like udev is getting closer to making that happen.
Make sure you put the new config files in place that need updating by running etc-update. If you don't, then it won't save your current /dev folder in /lib/udev-state/devices/devices.tar.bz2 . Even if your not planning on using the default devices.tar.bz2 and want to run a pure udev system, it won't have the necessary scripts in place to use udev.
7. Edit the scripts: If you are satisfied running the default Gentoo setup for now you can skip this section. Sooner or later you won't have to make this choice anyway. To run a pure udev system though edit the two scripts below.
If you are using >=baselayout-1.8.6.13-r1 you do not have to edit /etc/init.d/halt.sh or /sbin/rc. You will edit another file. See next section. If you are not using this baselayout or greater than edit these two file.
/etc/init.d/halt.sh
If you just comment out in this file (as root) where the blue ## are you will stop it from saving the state of /dev into the devices.tar.bz2 file when you shut down. This part of the script where it saves the /dev state is near the top of halt.sh
# We need to properly terminate devfsd to save the permissions
if [ -n "`ps --no-heading -C 'devfsd'`" ]
then
ebegin "Stopping devfsd"
killall -15 devfsd &>/dev/null
eend $?
elif [ ! -e /dev/.devfsd -a -e /dev/.udev ]
then
ebegin "Saving device nodes"
##cd /dev
##try tar -jclpf "/tmp/devices-$$.tar.bz2" *
##try mv -f "/tmp/devices-$$.tar.bz2" /lib/udev-state/devices.tar.bz2
eend 0
fi
/sbin/rc
There is just one line in this file (as root) to comment out where the blue ## is at. This will prevent /sbin/rc from populating /dev from the contents of devices.tar.bz2 file when you start up.
# Fix weird bug where there is a /dev/.devfsd in a unmounted /dev
mymounts="$(awk '($3 == "devfs") { print "yes"; exit 0 }' /proc/mounts)"
if [ -e "/dev/.devfsd" -a "${mymounts}" != "yes" ]
then
rm -f /dev/.devfsd
fi
if [ "${udev}" = "yes" ]
then
ebegin "Mounting ramfs at /dev"
try mount -n -t ramfs none /dev
eend $?
ebegin "Configuring system to use udev"
einfo " Populating /dev with device nodes..."
##try tar -jxpf /lib/udev-state/devices.tar.bz2 -C /dev
populate_udev
if [ -e /proc/sys/kernel/hotplug -a -x /sbin/hotplug ]
then
einfo " Using /sbin/hotplug for udev management..."
elif [ -e /proc/sys/kernel/hotplug ]
then
einfo " Setting /sbin/udev as hotplug agent..."
echo "/sbin/udev" > /proc/sys/kernel/hotplug
else
ewarn " Kernel was not compiled with hotplug support!"
fi
eend 0
# Create problematic directories
mkdir -p /dev/{pts,shm}
# Same thing as /dev/.devfsd
touch /dev/.udev
8. With the new baselayout-1.8.6.13-r1 you will need to edit /etc/conf.d/rc instead of the two scripts above. This is the relevant parts: (default setting)
# Set to "yes" if you want to save /dev to a tarball on shutdown
# and restore it on startup. This is useful if you have a lot of
# custom device nodes that udev do not handle/know about.
# (ONLY used by UDEV enabled systems!)
RC_DEVICE_TARBALL="yes"
# Set to "yes" if you want devfsd to start upon bootup. This is
# the default for Gentoo.
# Set to "no" only if you understand the full implications. A
# number of files may need to be altered (i.e. /etc/inittab,
# /etc/fstab, etc.).
# Also note that it does _NOT_ start for UDEV enabled systems,
# even if RC_DEVFSD_STARTUP="yes" ...
RC_DEVFSD_STARTUP="yes"
After a lot of trial and error. This is how you can setup these options: (Note: do not use 'devfs=nomount', the /sbin/rc is not looking for that option, it looks for 'nodevfs')
This is default setting. You can still boot to Devfs or Udev. If have the same or different kernel setup to use either, then have the proper options shown below for lilo or grub (ie. gentoo=noudev or gentoo=nodevfs)
Devfs or Udev (with Tarball)
RC_DEVICE_TARBALL="yes"
RC_DEVFSD_STARTUP="yes"
This next setting is to Not use the Tarball (devices.tar.bz2), but still be able to boot to devfs if want. If have the same or different kernel setup to use either, then have the proper options shown below for lilo or grub (ie. gentoo=noudev or gentoo=nodevfs)
Devfs or Udev (without Tarball)
RC_DEVICE_TARBALL="no"
RC_DEVFSD_STARTUP="yes"
This next setting is to Not use the Tarball or Do use the Tarball (devices.tar.bz2). But you will not be able to boot to Devfs at all!
Udev (with or without Tarball) and NO Devfs
RC_DEVICE_TARBALL="yes"
RC_DEVFSD_STARTUP="no"
OR
RC_DEVICE_TARBALL="no"
RC_DEVFSD_STARTUP="no"
After this many variables have been introduced, I can't wait for Devfs to be totally gone, so it is no longer an option!
9. If this is a new install and configuring it for a Pure UDEV system, or you get an error when you finally reboot after installing udev and setting it correctly like this: WARNING: Unable to open an initial console. It is because there is no /dev/console and /dev/null. What is happening is that /dev/console is needed before udev is populating the /dev folder. You can try this by manually deleting all static devices in /dev folder from another system, then rebooting to the udev system. You will get the console error. You will also notice that it is faulting at a time before it normally loads udev. If you just make /dev/console though it will then fail for /dev/null. So it needs both of those static in /dev, at least for the time being. The fix for now is to manually create them in your /dev folder.
cd /dev
mknod -m 660 console c 5 1
mknod -m 660 null c 1 3
This will create the /dev/console and /dev/null statically in your /dev folder.
10. NVIDIA DRIVERS: Use nvidia-kernel-1.0.5336-r1 and nvidia-glx-1.0.5336-r1 . They work with udev/sysfs. If you use these you will be able to boot up to X. They are masked right now so not stable listed. Have not had any problems though. If you don't want or cannot get them, see problem devices below on how to proceed.
Also as of udev-021 there is a new binary called /sbin/udevstart . If have problems nvidia devices not being created in /dev , even though using the correct nvidia drivers and worked before, see problem devices below on nvidia.
11. This should be the last thing your need to edit: Lilo.conf or Grub. (See problem devices below before you reboot).
If you did not compile DEVFS into the kernel. You are set to go. There is nothing you need to add to the boot-loaders. If you did compile DEVFS into the kernel (Did you compile Devfs to automatically load at boot? If so, go back and recompile the kernel without that option. Last warning!) You need to make a couple decisions. Gentoo will want to load devfs at boot if you compiled it into the kernel, even if you have udev. So here are a few options:
Option 1: Don't load devfs, use udev: You will need to add --> gentoo=nodevfs
Option 2: Don't load udev, use devfs: You will need to add --> gentoo=noudev
Option 3: Have two options in grub or lilo that let you boot to the same kernel, but with either udev or devfs: You need to add two boot options to lilo or grub. One with first option, the other with second option.
Lilo examples:
Option 1: Don't load devfs, use udev.
# Udev system mm1 2.6.3 kernel
image ="/boot/bzImage-2.6.3-rc1-mm1"
root="/dev/hdb2"
label="GentooUDEV"
append = "gentoo=nodevfs ide0=ata66 ide1=ata66 hdc=ide-cd"
read-only
Option 2: Don't load udev, use devfs.
# Devfs system mm1 2.6.3 kernel
image ="/boot/bzImage-2.6.3-rc1-mm1"
root="/dev/hdb2"
label="GentooUDEV"
append = "gentoo=noudev ide0=ata66 ide1=ata66 hdc=ide-cd"
read-only
Option 3: Choose which to use at boot.
# Udev system mm1 2.6.3 kernel
image ="/boot/bzImage-2.6.3-rc1-mm1"
root="/dev/hdb2"
label="GentooUDEV"
append = "gentoo=nodevfs ide0=ata66 ide1=ata66 hdc=ide-cd"
read-only
# Devfs system mm1 2.6.3 kernel
image ="/boot/bzImage-2.6.3-rc1-mm1"
root="/dev/hdb2"
label="GentooDEVFS"
append = "gentoo=noudev ide0=ata66 ide1=ata66 hdc=ide-cd"
read-only
Grub example: Pretty much the same, just different boot-loader.
Option 1: Don't load devfs, use udev.
title=Gentoo UDEV
root (hd0,0)
kernel (hd0,0)/bzImage-2.6.3-rc1-mm1 root=/dev/hda3 gentoo=nodevfs
If you did not compile DEVFS in the kernel and want to at a later date, recompile your kernel with DEVFS support. Then just go back and edit your boot-loader and add the appropriate changes like above and use one or the other or both. Just can't use udev or devfs at the same time. Sorry, one per customer. Again, I stress: Do Not compile the Kernel to Automatically load Devfs at Boot!!!
12. Problem Devices
Edit the devices.tar.bz2: Some people are opting to use the default Gentoo udev install and simply change their devices.tar.bz2 to contain only the devices that they need that are not being created by udev. So if your wanting to do this for devices like console and null and/or others. One simple way using using Ark. There are other ways graphically and commandline. I simply moved devices.tar.bz2 to a temp folder in Home, Viewed it, selected everything but console and null and said delete. It did it, then complained that delete failed, but it didn't. Saved the file. Rechecked and only those two devices are there. Then you can replace the old devices.tar.bz2 with this one. Just make sure you don't edit the scripts to not use the tarball if doing it this way. If your using the Tarball this way, you would want to leave RC_DEVICE_TARBALL="yes"
Nvidia Drivers: Nvidia-kernel-1.0.5336-r1 and nvidia-glx-1.0.5336-r1 will work with udev/sysfs. By the way, it is standard procedure to include nvidia modules in /etc/modules.autoload.d/your_kernel. So if you are using the above mentioned nvidia drivers and X is not starting because of no /dev/nvidia#, then make sure you have added it to autoload with the other modules to autoload at boot. If you don't want or cannot get them to work. Follow this:
For right now you will probably have to manually create the nvidia# and nvidiactl devices in /dev. One way of doing this that I use is just add it to your /etc/conf.d/local.start file like so:
mknod -m 660 /dev/nvidia0 c 195 0
mknod -m 660 /dev/nvidia1 c 195 1
mknod -m 660 /dev/nvidiactl c 195 255
Now sure how many devices you need. I just create two and haven't had a problem, just change the minor number to match. When udev starts putting nvidia drivers in /dev,or you switch to first mentioned drivers, you will see an error at boot, that the devices already exist. Then you can just remove the lines.
If you install the nvidia-kernel-1.0.5336-r1.ebuild and glx drivers get this error at bootup: Error: API mismatch: the NVIDIA kernel module is version 1.0.4480, but this X module is version 1.0.5336. Please be sure that your kernel module and all NVIDIA driver files have the same driver.
Solution is to look in your /lib/modules/your_kernel/video folder and make sure you only have one driver in there for nvidia. It should be labeled nvidia.ko if you installed 1.0.5336-r1 . If there is another remove it, if that don't work, unmerge nvidia drivers and remerge the 1.0.5336-r1 only.
If you plan on switching back and forth between a Devfs and Udev system. The first time you restart the Devfs system you will have to reload the nvidia-kernel and nvidia-glx. Emerging nvidia-kernel also did not make the devices for me and had to mknod them. This might have been when trying to get all the details about this new layout also, so it might make your devices.
Nvidia/Alsa Devices: As of udev-021 there is a new binary /sbin/udevstart. Have not used versions with this new binary until emerged udev-023-r1, then ran into the problem with NO nvidia devices and only one alsa device (/dev/snd/controlC0) being created. So if you have installed version 021 and up and find your self rebooting and sitting their looking at a command-line login and no X. Run as root: /sbin/udevstart . It will create the devices and you can then exit back to user and run: startx . Have been informed this is a nvidia and alsa package problem and not a problem with udev.
Instead of having to manually running /sbin/udevstart at login, you can add it to the top of your /etc/conf.d/local.start file.
PPP Device: This appears to be one of the devices still needing the be ported to sysfs, so cannot make a udev rule to create it either. If you need a /dev/ppp you will have to manually create it. You could add it to your local.start like the nvidia device. Others have changed the tarball to just contain devices they need that aren't being created. I will try to add how to do that later. If want to add it to your /etc/conf.d/local.start just add this line:
mknod -m 660 /dev/ppp c 108 0
Mice, Meese and Mouses: For those of you that find your mouse doesn't work in udev. It really is not a udev problem it is how you have configured it in the past. Udev (at this time) has 4 device locations you can use for mice.
/dev/input/mice
/dev/input/mouse0 (there will be mouse1, mouse2,.. if you have more, but mouse0 is for 1st mouse)
/dev/misc/psaux (which has symlink /dev/psaux)
So whichever you are using (ie. mouse#, mice or psaux), just make sure your /etc/X11/XF86Config-4 or XF86Config has the correct location for the device. You could change the location in /etc/udev/udev.rules but then each time you update udev you will have to add that correction, so better off editing the XF86Config-4 or XF86Config file.
13. You should be able to reboot now and test your udev system out. You should now see this at boot.
mounting sysfs at /sys
mounting ramfs at /dev
configuring system to use udev
populating /dev with device nodes
using /sbin/hotplug for udev management
There are a few other issues adding at the bottom here for things have seen on the forums.
1. Setfont: If you see a Setfont error at boot time, emerge the latest kbd: emerge -U kbd
2. Udev-009: Version 009 will not compile with sysfsutils-0.4.0. You will need to downgrade to sysfsutils-0.3.0, then emerge udev-009, then you can emerge sysfsutils-0.4.0 again. There is a bug report on it. The ebuild for udev-011 should be out soon. This shouldn't be a problem anymore, cause you should be using a newer udev version.
3. Dynamic Device Creation: Some of you are wonder about the dynamic device creation that udev is suppose to be performing. It pretty much is populating /dev with most devices now. Some people have reported success in their scanner or mouse or camera device being created. My mouse or scanner (scsi emulated) doesn't work with udev though. No device created. You won't see this either with the way Gentoo has UDEV setup right now (This only applies to those using the devices.tar.bz2).
LINKS:
German Udev Primer translation (Thanks to: Alexander Minges) Udev Primer: German
DSD's Guide on how to Write Udev Rules: Writing udev rules.
Right now there is a pretty good Post going at Gentoo Forums on UDEV: Gentoo Forum Thread.
Snippet of How to Write UDev Rules: Using DSD's Guide on how to Write UDEV Rules. Wanted to see how easy it was. So I picked the device most recently working with udev, my Microtek Scanner. Turned out to be very easy.
First I know that my scanner device in /dev is /dev/sg0. Can also use tail -f /var/log/syslog if have debug on hotplug turned on and see something like this:
Feb 25 09:16:17 decibels default.hotplug: arguments (scsi_generic) env (OLDPWD=/ DEVPATH=/class/scsi_generic/sg0 ...
So using his information I picked out the best non changing identifiers.
bash-2.05b# find | grep sg0
./class/scsi_generic/sg0
./class/scsi_generic/sg0/device
./class/scsi_generic/sg0/dev
./cdev/major/sg0
Based on that response:
bash-2.05b# udevinfo -a -p /sys/class/scsi_generic/sg0
device '/sys/class/scsi_generic/sg0' has major:minor 21:0
looking at class device '/sys/class/scsi_generic/sg0':
SYSFS{dev}="21:0"
follow the class device's "device"
looking at the device chain at '/sys/devices/platform/host0/0:0:0:0':
BUS="scsi" <------ Picked this.
ID="0:0:0:0"
SYSFS{detach_state}="0"
SYSFS{type}="6"
SYSFS{device_blocked}="0"
SYSFS{queue_depth}="1"
SYSFS{scsi_level}="3"
SYSFS{vendor}=" "
SYSFS{model}="Scanner V6UPL " <----- Picked this. Yes, the spaces where there in the name.
SYSFS{rev}="1.00"
SYSFS{online}="1"
looking at the device chain at '/sys/devices/platform/host0':
BUS=""
ID="host0"
SYSFS{detach_state}="0"
looking at the device chain at '/sys/devices/platform':
BUS=""
ID="platform"
SYSFS{detach_state}="0"
Okay, let's see if can use that to make a rule to also call my scanner /dev/sg0 as /dev/scanner .
Appended to the end of /etc/udev/udev.rules: (Tested, don't need to add the spaces at end of model name).
# Microtek Scanner
BUS="scsi", SYSFS{model}="Scanner V6UPL", NAME="%k", SYMLINK="scanner"
I know that my XSane backend is microtek2.conf in /etc/sane.d folder. It looks for a scsi device, so added /dev/scanner to it. And started two scanner programs. Both of them now give me the choice of using /dev/sg0 or /dev/scanner. So works perfect.
What good is this? Well in this instance not much. Mainly an exercise. I mean one is just a symlink to /dev/sg0. But in other cases you might have multiple devices and want to tell which one is which. You can read DSD's Guide for more details. My next goal is to see if can make it replace /dev/sg0 with /dev/scanner. But that is for another day.
More to come...
Original file is here http://webpages.charter.net/decibelshelp/LinuxHelp_UDEVPrimer.html 没人用这个吗？都没什么回帖地说…… 没人用这个吗？都没什么回帖地说……
I have no time to compile kernel------- :mrgreen: pre6 本来是带udev的，后来因为ALSA和fstab有点问题，暂时没有包含，这个包可以在magiclinux.net上面下载。 不好用啊，alsa有问题。
还是设备文件好，缺什么mk一个，呵呵，兼容性没问题。 ok,but some problem with alsa! 嗯，这个东东更新很快，大家期待新版本好了。 顶了在说 thanks! 唉，明天去深圳找工作啊 …… 唉，明天去深圳找工作啊 ……
祝你一路顺风。 我回来了 。。。
页:
[1]