It's being uploaded right now, and the BK trees should already be uptodate.

There's a x86-64 update and IRDA updates here, and a number of USB storage fixes. The rest is pretty small.

I have created and attached a new version of my old-style FAT filesystem patch, this time for the 2.6.0 kernel. It can also be found on http://debian.frodo.looijaard.name/.

Some old implementation of the FAT standard mark the end of the directory file index by inserting a filename beginning with a byte 00. All entries after it should be ignored, even though they are not marked as deleted. At least some EPOC releases (an OS used on Psion PDAs, for example) still use this policy.

The included patch adds the `oldfat' mount option for FAT-based filesystems. Without it, doing an 'ls' on old-style FATs will show a lot of garbage, both old files that have been deleted, and bogus entries that have never been filled.

If you do not use the `oldfat' mount option, FAT filesystems should work exactly as before. I have been very careful not to change the logic of the FAT driver, in order not to break anything. In fact, the patch could probably be optimized a bit, but I wanted to keep it as risk-free as possible.

It should be safe to mount a normal FAT filesystem with the `oldfat' mount option. I have been doing that on and off with some local Win98 filesystems without any trouble. Actually, the only reason I have introduced the mount option is to keep the new logic strictly seperated from the old driver.

All feedback would be very welcome. This patch is released under the GPL. Feel free to include it in stock kernels.

Debian users can install the .deb on http://debian.frodo.looijaard.name and have the patch applied automatically when compiling 2.6.x kernels.

The new cluster for directory entries must be initialized by 0x00. And, when the directory entry is deleted, the name[0] is updated by 0xe5 not 0x00.

So, if the name[0] is 0x00, it after, all bytes in cluster is 0x00.

The fat driver can stop at name[0] == 0x00, but this is just optimization. The behavior shouldn't change by this.

I looked at the spec, and yes, that is how the spec reads:

If DIR_Name[0] == 0x00, then the directory entry is free (same as for 0xE5), and there are no allocated directory entries after this one (all of the DIR_Name[0] bytes in all of the entries after this one are also set to 0). The special 0 value, rather than the 0xE5 value, indicates to FAT file system driver code that the rest of the entries in this directory do not need to be examined because they are all free.

I guess the original poster has found filesystems which have a 0 followed by garbage. In cases like that, the cardinal rule for FAT is WWDD (What Would DOS Do)... since I'm pretty sure DOS stops examining at that point, we should do the same.

It's the same thing as with using 0xF8 for ending clusters; it's correct according to spec, but WWDD says 0xFF is the right thing.

The new cluster for directory entries must be initialized by 0x00. This is required by spec.

If cluster has garbage, the fat driver needs to do such the following part. Stop at DIR_Name[0] == 0 is not enough, and I don't think DOS does this.

"stop when DIR_Name[0] == 0" should be added after cleanup. The option is not needed.

Honestly, I wouldn't like to add the "add a new DIR_Name[0] = 0" part. The option is added easy, but it is not removed easy. And we must maintain it. (BTW, looks like that patch is buggy)

Those stuff makes a change of the normal path difficult really. At the same reason, I removed the fat_cvf stuff.

I have attached a newer, better behaving version of my patch:

• Implements new mount option oldfat for FAT-derived filesystems.
• Stops scanning dirs when DIR_Name[0] = 0 when oldfat is set
• Writes a 0 to the next entry DIR_Name[0] when overwriting an entry which has DIR_Name[0] = 0 when oldfat is set

It has been tested with both msdos and vfat filesystems and seems to work well (unlike the patch of a few days ago, which had some issues).

Once you get around to cleaning up the code and making the stop-scanning-dirs-on-zero the default way, the patch can be shrunken to include only the third item.

The DOS situation is not so much that 0 is an end-of-dir marker. It marks that this entry, and all following entries, has never been used.

For the time being there is no justification for "oldfat". The only place where this behaviour has been reported (not only by you, I saw several references) is on Psion PDAs. So "psion" would be a more obvious name, if a mount option is needed.

And maybe no mount option is needed.

Your 2nd and 3rd points can be done always, I think, unless our FAT code should mimic the DOS FAT behaviour (on non-DOS filesystems).

another update of the patch, which addresses some of the reactions and concerns which I got in reply:

• The mount option is now called `epoc' instead of `oldfat'
• fat_search_long now jumps directly to EODir when it finds a zero-marked entry (it took some hard looking, but I belief this is safe).
• fat_readdirx logic is slightly simplified (but can't jump to EODir on a zero-marked entry, regrettably).

Thanks for your feedback!

I'll try to keep this patch up-to-date with new 2.6 kernels. The latest version can always be found on http://debian.frodo.looijaard.name/

I have some time this year to work on an encrypted filesystem for Linux. I have surveyed various LUG's, tested and reviewed code for currently existing implementations, and have started modifying some of them. I would like to settle on a single approach on which to focus my efforts, and I am interested in getting feedback from the LKML community as to which approach is the most feasible.

This is the feature wish-list that I have compiled, based on personal experience and feedback I have received from other individuals and groups:

• Seamless application to the root filesystem
  • Layered over the entire root filesystem
  • Unencrypted pass-through mode with minimal overhead
  • Files are marked as ``encrypted'' or ``unencrypted'' and treated accordingly by the encryption layer
• Key->file association
  • As opposed to key->blkdev or key->directory granularity
  • No encryption metafiles in directories, instead placing that information into Extended Attributes
  • May break some backup utilities that are not EA-aware; may require another mode where encryption metadata is stored in a header block on the encrypted file
  • Directories can be flagged as ``encrypted-only'', where any new files created in that directory are, by default, encrypted, with the key and permissions defined in the directory's metadata
  • Processes may have encryption contexts, whereby any new files they create are encrypted by default according to the process' authentication
  • Make as much metadata about the file as confidential as possible (filesize, executable bit, etc.)
• Pluggable encryption (I wouldn't mind using a block cipher in CTR mode)
• Authentication via PAM
  • pam_usb
  • Bluetooth
  • Kerberos
  • PAM checks for group membership before allowing access to certain encrypted files
• Rootplug-based LSM to provide key management (necessary to use LSM?)
• Secret splitting and/or (m,n)-threshold support on the keys
• Signatures on files flagged for auditing in order to detect attempts to circumvent the encryption layer (via direct modifications to the files themselves in the underlying filesystem)
• Ad-hoc groups for access to decrypted versions of files
  • i.e., launch web browser, drop group membership by default (like capability inheritance masks) so that the browser does not have access to decrypted files by default; PAM module checks for group membership before allowing access (explicit user authorization on application access requests)
• Userland utilities to support encrypted file management
• Extensions to nautilus and konqueror to be able to use these utilities from a common interface (think: right-click, encrypted)
• Distro installation integration
• Transparent shredding, where the underlying filesystem supports it
• Versioning and snapshots (CVS-ish behavior)
• Design to work w/ SE Linux

These are features that have been requested, but are not necessarily hard requirements for the encrypted filesystem. They are just suggestions that I have received, and I am not convinced that they are all feasible.

There are several potential approaches to an encrypted filesystem with these features, all with varying degrees of modification to the kernel itself, each with its own set of advantages and disadvantages.

Options that I am aware of include:

• NFS-based (CFS, TCFS)
  • CFS is mature
  • Performance issues
  • Violates UNIX semantics w/ hole behavior
  • Single-threaded
• Userland filesystem-based (EncFS+FUSE, CryptoFS+LUFS)
  • Newer solutions, not as well accepted or tested as CFS
  • KDE team is using SSHFS+FUSE
• Loopback (cryptoloop) encrypted block device
  • Mature; in the kernel
  • Block device granularity; breaks most incremental backup applications
• LSM-based
  • Is this even possible? Are the hooks that we need there?
• Modifications to VFS (stackable filesystem, like NCryptfs)
  • Very low overhead claimed by Erez Zadok
  • Full implementation not released
  • Key->directory granularity
  • Evicts cleartext pages from the cache on process death
  • Uses dcache to store attaches
  • Other niceties, but it's not released...

My goal is to develop an encrypted filesystem ``for the desktop'', where a user can right-click on a file in konqueror or nautilus and check the ``encrypted'' box, and all subsequent accesses by any processes to that file will require authentication in order for the file to be decrypted. I have already made some modifications to CFS to support this functionality, but I am not sure at this moment whether or not CFS is the best route to go for this.

I have had requests to write a kernel module that, when loaded, transparently starts acting as the encryption layer on top of whatever root filesystem is mounted. For example, an ext3 partition may have encrypted files strewn about, which are accessible only after loading the module (and authenticating, etc.).

Ehh, Coda's kernel module does just that. It is used by the userspace cache manager of the Coda Distributed File System.

http://www.coda.cs.cmu.edu/

But several other projects seem to be using it,

http://uservfs.sourceforge.net/
http://dav.sourceforge.net/

The interface to userspace a bit clumsy to work with, but there are kernel modules for FreeBSD/NetBSD/Solaris and an experimental one for Windows 2000/NT/XP, which makes any significant changes a bit of a pain.

It does have it's pecularities, reads and writes are not passed up to userspace, only the open and close VFS calls. This makes the module reasonably quite simple as it doesn't have to deal with VM issues and it isn't susceptible to deadlocks,

   app wants to read data from a file ->
   userspace application requires memory allocation to provide this data ->
   VM tries to write out dirty data associated with the Coda mountpoint ==
   deadlock

So whole file caching keeps the kernel module more portable and simplifies the userspace code. But it makes things like streaming reads/writes or quotas impossible. If you want to provide encryption there you would have to store an unencrypted copy of every open file somewhere on disk or in ramfs/tmpfs and incur the cost of (de)crypting (and (de)compressing) whenever it is opened or closed.

I'm planning on submitting FUSE for inclusion into 2.7 (and maybe 2.6 if that is acceptable). I feel that FUSE has been maturing lately with some very interesting applications.

Here are the reasons for _not_ including it:

1. There are already two filesystems in kernel that are perfectly usable for this purpose: NFS and CODA
2. There are currently two competing userspace filesystem layers that have about the same "market share": LUFS and FUSE. Why should we prefer one over the other

I'll try to refute myself on these points:

1. Both NFS and CODA were designed for something different. IOW they are not optimized for the purpose of supporting userspace filesystems. NFS is slow and there are problems with coherency of the underlying and the mounted filesystem. CODA does not support random file access (or even streaming), only reading whole files. It also has a miriad of small problems when used for exporting a userspace fs (I've been personally burned many times while doing AVFS over CODA).
2. This one is harder to get rid of, especially because I don't want to delve into the technical merits of one or the other (I'd be a bit biased). But I have compared both the kernel interface and the library API of LUFS and FUSE and they are very similar. And that is a good thing, because it makes possible to support LUFS filesystems with the FUSE kernel module and vica versa.

1. In FUSE normal writes go through the cache, so no dirty pages are created. The only possibility to create dirty pages is with shared writable mapping, and this is rare
2. Userspace filesystem app can be multithreaded, so probably write can be satisfied even if read is pending.
3. The 2.6 kernel provides asynchronous page writeback, so even if a writeback is blocking forever the VM will continue to try to free up memory.
4. If no memory can be freed, then the allocation will fail, so the read will fail: no deadlock.
5. Even if the memory allocation was caused by a page fault, which cannot fail, the worst case is that the OOM killer is invoked, and memory is freed up: no deadlock.

So with the asynchronous page writeback mechanism the 2.6 kernel is very immune to this kind of deadlock. I have tested this with a little program which behaves very nastily in this respect (I can send you this if you're interested). And I was able to invoke the OOM killer if there was no swap, but there was never a deadlock.

this is not the "right way" to do it, but it works here and now for those who have P4HT processors.

A while back we had an lkml thread about the problem of running low priority tasks on hyperthread enabled cpus in SMP mode. Brief summary: If you run a P4HT in uniprocessor mode and run a cpu intensive task at nice +20 (like setiathome), the most cpu it will get during periods of heavy usage is about 8%. If you boot a P4HT in SMP mode and run a cpu intensive task at nice +20 then if you run a task even at nice -20 concurrently, the nice +20 task will get 50% of the cpu time even though you have a very high priority task. So ironically booting in SMP mode makes your machine slower for running background tasks.

This patch (together with the ht base patch) will not allow a priority >10 difference to run concurrently on both siblings, instead putting the low priority one to sleep. Overall if you run concurrent nice 0 and nice 20 tasks with this patch your cpu throughput will drop during heavy periods by up to 10% (the hyperthread benefit), but your nice 0 task will run about 90% faster. It has no effect if you don't run any tasks at different "nice" levels. It does not modify real time tasks or kernel threads, and will allow niced tasks to run while a high priority kernel thread is running on the sibling cpu.

http://ck.kolivas.org/patches/2.6/2.6.1/experimental/. There are other patches that go with it which is why these have slight offsets but should work ok.

Criticism was laid at the previous patch for the way a more "nice" task might never run on the sibling cpu if a high priority task was running. This patch is a much better solution.

What this one does is the following; If there is a "nice" difference between tasks running on logical cores of the same cpu, the more "nice" one will run a proportion of time equal to the timeslice it would have been given relative to the less "nice" task. ie a nice 19 task running on one core and the nice 0 task running on the other core will let the nice 0 task run continuously (102ms is normal timeslice) and the nice 19 task will only run for the last 10ms of time the nice 0 task is running. This makes for a much more balanced resource distribution, gives significant preference to the higher priority task, but allows them to benefit from running on both logical cores.

This seems to me a satisfactory solution to the hyperthread vs nice problem. Once again this is too arch. specific a change to sched.c for mainline, but as proof of concept I believe it works well for those who need something that works that they can use now.

http://ck.kolivas.org/patches/2.6/2.6.1/experimental/

The stuff on my website is incremental with my other experiments, but the attached patch applies cleanly to 2.6.1

Glad you agree.

From the anandtech website a description of the P4 Prescott (next generation IA32) with hyperthreading shows this with the new SSE3 instruction set:

"Finally we have the two thread synchronization instructions ??? monitor and mwait. These two instructions work hand in hand to improve Hyper Threading performance. The instructions work by determining whether a thread being sent to the core is the OS??? idle thread or other non-productive threads generated by device drivers and then instructing the core to worry about those threads after working on whatever more useful thread it is working on at the time."

At least it appears Intel are well aware of the priority problem, but full priority support across logical cores is not likely. However I guess these new instructions are probably enough to work with if someone can do the coding.

these instructions can be used in the idle=poll code instead of rep-nop. This way idle-wakeup can be done via the memory bus in essence, and the idle threads wont waste CPU time. (right now idle=poll wastes lots of cycles on HT boxes and is thus unusable.)

for lowprio tasks they are of little use, unless you modify gcc to sprinkle mwait yields all around the 'lowprio code' - not very practical i think.

Looks like the kernel is the only thing likely to be smart enough to do this correctly for some time yet.

Nick, any chance of seeing something like this in your sched domains? (that would be the right way unlike my hacking sched.c directly for a specific architecture).

no, there's no way for the kernel to do this 'correctly', without further hardware help. mwait is suspending the current virtual CPU a bit better than rep-nop did. This can be exploited for the idle loop because the idle loop does nothing so it can execute the rep-nop. (mwait can likely also be used for spinlocks but that is another issue.)

user-space code that is 'low-prio' cannot be slowed down via mwait, without interleaving user-space instructions with mwait (or with rep-nop).

this is a problem area that is not solved by mwait - giving priority to virtual CPUs should be offered by CPUs, once the number of logical cores increases significantly - if the interaction between those cores is significant. (there are SMT designs where this isnt an issue.)

This release contains a big USB merge, architecture updates (Alpha, SPARC, x86/64), SCSI driver updates (cpqarray and MPT fusion), smbfs support for CIFS Unix extensions and large files (backported from 2.6), "ACPICA" merge and ACPI fixes, merge jgarzik's net driver fixes, amongst others.

This is probably the last -pre.

This patch forward ports a few important fixes from the 2.4 driver. This changes have been well tested.

Please apply.

Changelog:

• Update maintainer email address
• Mark pci_device_id list with __devinitdata.

Greg: rmk and hch checked this and found no problem. A bunch of other drivers are doing the same.

• Set correct protocol type on packet receive (this caused the kernel to drop all packets received)
• Add #ifdef DEBUG around debug printk()

Greg, Christoph: dprintk()/etc would be nice, but we're not trying a rewrite here. Yes its ugly but its consistent with the rest. Maybe we can do it for the whole driver, later on.

• ioctl: Add missing size checks before copying data from userspace.

The bulk of this is an ACPI update, but there's USB, ia-64, i2c, XFS and PCI hotplug updates here too.

Please don't send in anything but critical fixes until after the final 2.6.2 release.

It's my pleasure to announce that Linux Netwosix 1.0 is released and runs the kernel 2.6.1 by default. It seems to be the first linux distro with this kernel. I'm hopeful on this kernel. Linux Netwosix is a powerful and optimized Linux distribution for servers and Network Security related jobs. It can be also used for special operations as penetration test with its big collection of softwares and sources security oriented. It's a ligh distribution created for the requirements of every SysAdmin and it's very portable and highly configurable. Our philosophy is to give a big liberty of configuration to the SysAdmin. Only in this way he/she can configure a powerful and stable server machine. Linux Netwosix have also a powerful ports system +(Nepote) similar to the xBSD systems but more flexible and usable.

Here the announcement release:
http://www.netwosix.org/announce.html

Common problems and solutions with 2.6 input drivers:

Problems:

How do I get a list of the input devices in my system?
How can I check that the input drivers have found my devices correctly?

Solution:

'cat /proc/bus/input/devices' and 'dmesg' are your friends here. The first lists all devices known to the input core with their properties, and the latter shows the messages from boot. There you can spot any errors that happened in the probing process.

Problems:

I'm getting double clicks when I click only once.
My scroll wheel scrolls by two lines/screens instead of one.
My mouse moves too fast.

Solution:

Check your XFree86 config file.

You probably have two "mouse" entries there, one pointing to /dev/psaux and the other to /dev/input/mice, so that you can get both your PS/2 and USB mouse working on 2.4.

2.6 uses the input subsystem for both PS2 and USB, and thus both devices will report events from both mice, resulting in doubled events.

Remove either the /dev/psaux or /dev/input/mice entry, depending what suits you better for 2.4 compatibility should you ever need go back to 2.4.

Problems:

My mouse wheel is not working in X.
My Logitech (MousManPS/2) mouse stopped working in X.
My extra buttons don't work in X.

Solution:

Check your XFree86 config file.

Make sure the mouse protocol is set to "ExplorerPS/2", as that is what the 2.6 kernel exports to applications regardless of the real mouse type.

Make sure you have an "ZAxisMapping 4 5" entry.

Make sure you have an entry for remapping the extra buttons above 5.

Problem:

Kernel reports:
atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.

Solution:

Well, the kernel means what it says. XFree86 boldly goes and accesses the keyboard controller registers when it starts up. This is a bad thing to do, as it can conflict with the kernel using these registers at the same time. The kernel spots this and complains, and in most cases is not affected by the problem.

So, unless you are an XFree86 developer and can fix X, ignore this message.

Problem:

I get the message above, but I'm not running X.

Solution:

Other applications (for example kbdrate) may also access the keyboard controller. This will trigger the same message.

Fix your application / utility or ignore the message.

Problem:

My multimedia keys don't work at all and instead emit a message like this:

atkbd.c: Unknown key pressed (translated set 2, code 0x83 on isa0060/serio0).
atkbd.c: Use 'setkeycodes e003 <keycode>' to make it known.
atkbd.c: Unknown key released (translated set 2, code 0x83 on isa0060/serio0).
atkbd.c: Use 'setkeycodes e003 <keycode>' to make it known.

Solution:

Do what the kernel says. Use the setkeycodes utility with the suggested scncode value. For the keycode value, look into /usr/include/linux/input.h, where is a list of all defined Linux keycodes.

Then you can verify that the keyboard works correctly by using the evtest program:

evtest /dev/input/event#

Where # is the number of the input device that is your keyboard.

Problem:

setkeycodes refuses to work with keycodes above 127.

Solution:

Get a recent version of the kbd package, and recompile on a 2.6 kernel.

Problem:

Ok, evtest shows everything correctly, but I get incorrect keysyms assigned to these keys in XFree86.

Solution:

While the 2.6 kernel tries to use the "standard" scancodes as much as possible, it is not posible for all keys.

A good solution is to modify the XKB keyboard definition to match the scancodes one can obtain from 'showkeys -s', after the above problem is solved and the keys work in evtest.

An better solution would be to write a kernel-2.6 keyboard definition, as the scancodes are the same for every type of keyboard, independend of the hardware. This is called hardware abstraction.

A perfect solution would be to get X to use the event protocol. If you're an XFree86 developer, you might consider this.

Problem:

My PC Speaker is not beeping anymore in 2.6.

Solution:

Enable it in the kernel config. Go to Drivers->Input->Misc->PC Speaker.

Problem:

My Synaptics touchpad lost the ability of tap-to-click, scroll, etc.

Solution:

The easy solution is to pass psmouse.proto=imps on the kernel command line, or proto=imps on the psmouse module command line. This will restore 2.4 behavior.

A better solution is to download the new XFree86 Synaptics driver that cooperates with the input drivers nicely, from:

http://w1.894.telia.com/~u89404340/touchpad/index.html

This will allow you to configure the behavior of the touchpad in detail and give you all the features it can do, including palm detection and similar.

In case you want to get this running at the console, too, an updated GPM package can be found here:

http://www.geocities.com/dt_or/gpm/gpm.html

Problem:

When I switch my KVM, my PS/2 mouse goes all crazy.

Solution:

Use psmouse.proto=bare on the kernel command line, or proto=bare on the psmouse module command line.

Problem:

I'm getting these:

psmouse.c: PS/2 mouse at serio0 lost synchronization, throwing 2 bytes away.

Solution:

Check your mouse cable. If this only happens when you move your mouse in a certain way, fix the mouse cable or replace the mouse.

Check your kernel and harddisk settings. This message can also happen when the mouse interrupt is delayed more than one half of a second. Make sure DMA is enabled for your harddrive and CD-ROM. Kill your ACPI/APM battery monitoring applet. Try disabling ACPI, frequency scaling. Make sure your time is ticking correctly, often with frequency scaling it gets unreliable. Even if you're using the ACPI PM Timer as a clock source - actually this often leads to the above problem.

Problem:

My keyboard autorepeat is not as snappy as it used to be in the 2.5 series.

Solution:

Use atkbd.softrepeat=1 on the kernel command line, or "softrepeat=1" on atkbd module command line. This will enable kernel internal repeat generation, which is much more flexible and allows higher repeat rates and shorter repeat delays than the keyboard itself does.

Problem:

kbdrate doesn't work when I use atkbd.softrepeat.

Solution:

Get an up-to-date version of the kbd package. Recompile on 2.6.

Problem:

I've read through the whole file, and it did not help me at all!

Solution:

Either you didn't have any problem in the first place, or it's something that is not very often and thus not listed. Try contacting the driver author/maintainer, the kernel mailing list, or enter the problem into the Linux kernel bugzilla.

Here is a device driver for the IBM xSeries RSA service processor. The ibmasm driver is mainly intended to be used in conjunction with a user space API and systems management applications that need to get in-band access to the service processor, such as sending commands or waiting for events. For the remote video feature the driver relays remote mouse and keyboard events to user space. By itself the driver also allows the OS to make use the UART on the service processor board as a regular serial line.

The user interface to the driver is a custom file system. It does not use sysfs since the operations on the files are somewhat beyond the one file / one value rule for sysfs. Since it is not strictly a char driver I put it into the drivers/misc directory.

the attached patch fixes UML on 2.6.2-rc3-mm1:

• generic: dmapool.o depends on CONFIG_PCI
• x86: reshuffle the way TASK_SIZE is defined on x86. [UML relied on a specific order of definitions within the x86 header files, the 4/4 patch broke this assumption.]
• UML: sys_call_table.c: syscall layout changed
• UML: um_arch.c: handle_sysrq() changed

UML compiles & works fine with this patch applied.

I've released the 016 version of udev. It can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-016.tar.gz

rpms built against Red Hat FC1 are available at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-016-1.i386.rpm
with the source rpm at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-016-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